C++ Type traits
-by John Maddock and Steve Cleary
-This is a draft of an article that will appear in a future -issue of Dr Dobb's Journal
-Generic programming (writing code which works with any data type meeting a -set of requirements) has become the method of choice for providing reusable -code. However, there are times in generic programming when "generic" -just isn't good enough - sometimes the differences between types are too large -for an efficient generic implementation. This is when the traits technique -becomes important - by encapsulating those properties that need to be considered -on a type by type basis inside a traits class, we can minimise the amount of -code that has to differ from one type to another, and maximise the amount of -generic code.
-Consider an example: when working with character strings, one common -operation is to determine the length of a null terminated string. Clearly it's -possible to write generic code that can do this, but it turns out that there are -much more efficient methods available: for example, the C library functions strlen -and wcslen are usually written in -assembler, and with suitable hardware support can be considerably faster than a -generic version written in C++. The authors of the C++ standard library realised -this, and abstracted the properties of char -and wchar_t into the class char_traits. -Generic code that works with character strings can simply use char_traits<>::length -to determine the length of a null terminated string, safe in the knowledge that -specialisations of char_traits will use -the most appropriate method available to them.
-Type traits
-Class char_traits is a classic -example of a collection of type specific properties wrapped up in a single class -- what Nathan Myers termed a baggage class[1]. In the Boost type-traits -library, we[2] have written a set of very specific traits classes, each of which -encapsulate a single trait from the C++ type system; for example, is a type a -pointer or a reference type? Or does a type have a trivial constructor, or a -const-qualifier? The type-traits classes share a unified design: each class has -a single member value, a compile-time constant that is true if the type -has the specified property, and false otherwise. As we will show, these classes -can be used in generic programming to determine the properties of a given type -and introduce optimisations that are appropriate for that case.
-The type-traits library also contains a set of classes that perform a -specific transformation on a type; for example, they can remove a top-level -const or volatile qualifier from a type. Each class that performs a -transformation defines a single typedef-member type that is the result of -the transformation. All of the type-traits classes are defined inside namespace boost; -for brevity, namespace-qualification is omitted in most of the code samples -given.
-Implementation
-There are far too many separate classes contained in the type-traits library -to give a full implementation here - see the source code in the Boost library -for the full details - however, most of the implementation is fairly repetitive -anyway, so here we will just give you a flavour for how some of the classes are -implemented. Beginning with possibly the simplest class in the library, is_void<T> -has a member value that is true only if T is void.
-template <typename T>
-struct is_void
-{ static const bool value = false; };
-
-template <>
-struct is_void<void>
-{ static const bool value = true; };
-Here we define a primary version of the template class is_void, -and provide a full-specialisation when T is void. While full specialisation of a -template class is an important technique, sometimes we need a solution that is -halfway between a fully generic solution, and a full specialisation. This is -exactly the situation for which the standards committee defined partial -template-class specialisation. As an example, consider the class -boost::is_pointer<T>: here we needed a primary version that handles all -the cases where T is not a pointer, and a partial specialisation to handle all -the cases where T is a pointer:
-template <typename T>
-struct is_pointer
-{ static const bool value = false; };
-
-template <typename T>
-struct is_pointer<T*>
-{ static const bool value = true; };
-The syntax for partial specialisation is somewhat arcane and could easily -occupy an article in its own right; like full specialisation, in order to write -a partial specialisation for a class, you must first declare the primary -template. The partial specialisation contains an extra <…> after the -class name that contains the partial specialisation parameters; these define the -types that will bind to that partial specialisation rather than the default -template. The rules for what can appear in a partial specialisation are somewhat -convoluted, but as a rule of thumb if you can legally write two function -overloads of the form:
-void foo(T); -void foo(U);-
Then you can also write a partial specialisation of the form:
-template <typename T>
-class c{ /*details*/ };
-
-template <typename T>
-
-class c<U>{ /*details*/ };
-This rule is by no means foolproof, but it is reasonably simple to remember -and close enough to the actual rule to be useful for everyday use.
-As a more complex example of partial specialisation consider the class -remove_bounds<T>. This class defines a single typedef-member type -that is the same type as T but with any top-level array bounds removed; this is -an example of a traits class that performs a transformation on a type:
-template <typename T>
-struct remove_bounds
-{ typedef T type; };
-
-template <typename T, std::size_t N>
-struct remove_bounds<T[N]>
-{ typedef T type; };
-The aim of remove_bounds is this: imagine a generic algorithm that is passed
-an array type as a template parameter, remove_bounds
-provides a means of determining the underlying type of the array. For example remove_bounds<int[4][5]>::type
-would evaluate to the type int[5]. This example also shows that the
-number of template parameters in a partial specialisation does not have to match
-the number in the default template. However, the number of parameters that
-appear after the class name do have to match the number and type of the
-parameters in the default template.
Optimised copy
-As an example of how the type traits classes can be used, consider the -standard library algorithm copy:
-template<typename Iter1, typename Iter2> -Iter2 copy(Iter1 first, Iter1 last, Iter2 out);-
Obviously, there's no problem writing a generic version of copy that works -for all iterator types Iter1 and Iter2; however, there are some circumstances -when the copy operation can best be performed by a call to memcpy. -In order to implement copy in terms of memcpy -all of the following conditions need to be met:
--
-
- Both of the iterator types Iter1 and Iter2 must be pointers. -
- Both Iter1 and Iter2 must point to the same type - excluding const - and volatile-qualifiers. -
- The type pointed to by Iter1 must have a trivial assignment operator. -
By trivial assignment operator we mean that the type is either a scalar -type[3] or:
--
-
- The type has no user defined assignment operator. -
- The type does not have any data members that are references. -
- All base classes, and all data member objects must have trivial assignment - operators. -
If all these conditions are met then a type can be copied using memcpy
-rather than using a compiler generated assignment operator. The type-traits
-library provides a class has_trivial_assign, such that has_trivial_assign<T>::value
-is true only if T has a trivial assignment operator. This class "just
-works" for scalar types, but has to be explicitly specialised for
-class/struct types that also happen to have a trivial assignment operator. In
-other words if has_trivial_assign gives the wrong answer, it will give
-the "safe" wrong answer - that trivial assignment is not allowable.
The code for an optimised version of copy that uses memcpy -where appropriate is given in listing 1. The code begins by defining a template -class copier, that takes a single Boolean template parameter, and has a -static template member function do_copy -which performs the generic version of copy (in other words -the "slow but safe version"). Following that there is a specialisation -for copier<true>: again this defines a static template member -function do_copy, but this version uses -memcpy to perform an "optimised" copy.
-In order to complete the implementation, what we need now is a version of
-copy, that calls copier<true>::do_copy if it is safe to use memcpy,
-and otherwise calls copier<false>::do_copy to do a
-"generic" copy. This is what the version in listing 1 does. To
-understand how the code works look at the code for copy
-and consider first the two typedefs v1_t and v2_t. These use std::iterator_traits<Iter1>::value_type
-to determine what type the two iterators point to, and then feed the result into
-another type-traits class remove_cv that removes the top-level
-const-volatile-qualifiers: this will allow copy to compare the two types without
-regard to const- or volatile-qualifiers. Next, copy
-declares an enumerated value can_opt that will become the template
-parameter to copier - declaring this here as a constant is really just a
-convenience - the value could be passed directly to class copier.
-The value of can_opt is computed by verifying that all of the following
-are true:
-
-
- first that the two iterators point to the same type by using a type-traits - class is_same. -
- Then that both iterators are real pointers - using the class is_pointer - described above. -
- Finally that the pointed-to types have a trivial assignment operator using - has_trivial_assign. -
Finally we can use the value of can_opt as the template argument to -copier - this version of copy will now adapt to whatever parameters are passed -to it, if its possible to use memcpy, -then it will do so, otherwise it will use a generic copy.
-Was it worth it?
-It has often been repeated in these columns that "premature optimisation -is the root of all evil" [4]. So the question must be asked: was our -optimisation premature? To put this in perspective the timings for our version -of copy compared a conventional generic copy[5] are shown in table 1.
-Clearly the optimisation makes a difference in this case; but, to be fair, -the timings are loaded to exclude cache miss effects - without this accurate -comparison between algorithms becomes difficult. However, perhaps we can add a -couple of caveats to the premature optimisation rule:
--
-
- If you use the right algorithm for the job in the first place then - optimisation will not be required; in some cases, memcpy - is the right algorithm. -
- If a component is going to be reused in many places by many people then - optimisations may well be worthwhile where they would not be so for a single - case - in other words, the likelihood that the optimisation will be - absolutely necessary somewhere, sometime is that much higher. Just as - importantly the perceived value of the stock implementation will be higher: - there is no point standardising an algorithm if users reject it on the - grounds that there are better, more heavily optimised versions available. -
Table 1: Time taken to copy 1000 elements using copy<const T*, T*> -(times in micro-seconds)
-|
- Version - |
-
- T - |
-
- Time - |
-
| "Optimised" copy | -char | -0.99 | -
| Conventional copy | -char | -8.07 | -
| "Optimised" copy | -int | -2.52 | -
| Conventional copy | -int | -8.02 | -
-
Pair of References
-The optimised copy example shows how type traits may be used to perform -optimisation decisions at compile-time. Another important usage of type traits -is to allow code to compile that otherwise would not do so unless excessive -partial specialization is used. This is possible by delegating partial -specialization to the type traits classes. Our example for this form of usage is -a pair that can hold references [6].
-First, let us examine the definition of "std::pair", omitting the -comparision operators, default constructor, and template copy constructor for -simplicity:
-template <typename T1, typename T2>
-struct pair
-{
- typedef T1 first_type;
- typedef T2 second_type;
-
- T1 first;
- T2 second;
-
- pair(const T1 & nfirst, const T2 & nsecond)
- :first(nfirst), second(nsecond) { }
-};
-Now, this "pair" cannot hold references as it currently stands, -because the constructor would require taking a reference to a reference, which -is currently illegal [7]. Let us consider what the constructor's parameters -would have to be in order to allow "pair" to hold non-reference types, -references, and constant references:
-| Type of "T1" | -Type of parameter to initializing constructor | -
- T- |
-
- const T &- |
-
- T &- |
-
- T &- |
-
- const T &- |
-
- const T &- |
-
A little familiarity with the type traits classes allows us to construct a -single mapping that allows us to determine the type of parameter from the type -of the contained class. The type traits classes provide a transformation "add_reference", -which adds a reference to its type, unless it is already a reference.
-| Type of "T1" | -Type of "const T1" | -Type of "add_reference<const - T1>::type" | -
- T- |
-
- const T- |
-
- const T &- |
-
- T &- |
-
- T & [8]- |
-
- T &- |
-
- const T &- |
-
- const T &- |
-
- const T &- |
-
This allows us to build a primary template definition for "pair" -that can contain non-reference types, reference types, and constant reference -types:
-template <typename T1, typename T2>
-struct pair
-{
- typedef T1 first_type;
- typedef T2 second_type;
-
- T1 first;
- T2 second;
-
- pair(boost::add_reference<const T1>::type nfirst,
- boost::add_reference<const T2>::type nsecond)
- :first(nfirst), second(nsecond) { }
-};
-Add back in the standard comparision operators, default constructor, and -template copy constructor (which are all the same), and you have a std::pair -that can hold reference types!
-This same extension could have been done using partial template -specialization of "pair", but to specialize "pair" in this -way would require three partial specializations, plus the primary template. Type -traits allows us to define a single primary template that adjusts itself -auto-magically to any of these partial specializations, instead of a brute-force -partial specialization approach. Using type traits in this fashion allows -programmers to delegate partial specialization to the type traits classes, -resulting in code that is easier to maintain and easier to understand.
-Conclusion
-We hope that in this article we have been able to give you some idea of what -type-traits are all about. A more complete listing of the available classes are -in the boost documentation, along with further examples using type traits. -Templates have enabled C++ uses to take the advantage of the code reuse that -generic programming brings; hopefully this article has shown that generic -programming does not have to sink to the lowest common denominator, and that -templates can be optimal as well as generic.
-Acknowledgements
-The authors would like to thank Beman Dawes and Howard Hinnant for their -helpful comments when preparing this article.
-References
--
-
- Nathan C. Myers, C++ Report, June 1995. -
- The type traits library is based upon contributions by Steve Cleary, Beman - Dawes, Howard Hinnant and John Maddock: it can be found at www.boost.org. -
- A scalar type is an arithmetic type (i.e. a built-in integer or floating - point type), an enumeration type, a pointer, a pointer to member, or a - const- or volatile-qualified version of one of these types. -
- This quote is from Donald Knuth, ACM Computing Surveys, December 1974, pg - 268. -
- The test code is available as part of the boost utility library (see - algo_opt_examples.cpp), the code was compiled with gcc 2.95 with all - optimisations turned on, tests were conducted on a 400MHz Pentium II machine - running Microsoft Windows 98. -
- John Maddock and Howard Hinnant have submitted a "compressed_pair" - library to Boost, which uses a technique similar to the one described here - to hold references. Their pair also uses type traits to determine if any of - the types are empty, and will derive instead of contain to conserve space -- - hence the name "compressed". -
- This is actually an issue with the C++ Core Language Working Group (issue - #106), submitted by Bjarne Stroustrup. The tentative resolution is to allow - a "reference to a reference to T" to mean the same thing as a - "reference to T", but only in template instantiation, in a method - similar to multiple cv-qualifiers. -
- For those of you who are wondering why this shouldn't be const-qualified, - remember that references are always implicitly constant (for example, you - can't re-assign a reference). Remember also that "const T &" - is something completely different. For this reason, cv-qualifiers on - template type arguments that are references are ignored. -
Listing 1
-namespace detail{
-
-template <bool b>
-struct copier
-{
- template<typename I1, typename I2>
- static I2 do_copy(I1 first,
- I1 last, I2 out);
-};
-
-template <bool b>
-template<typename I1, typename I2>
-I2 copier<b>::do_copy(I1 first,
- I1 last,
- I2 out)
-{
- while(first != last)
- {
- *out = *first;
- ++out;
- ++first;
- }
- return out;
-}
-
-template <>
-struct copier<true>
-{
- template<typename I1, typename I2>
- static I2* do_copy(I1* first, I1* last, I2* out)
- {
- memcpy(out, first, (last-first)*sizeof(I2));
- return out+(last-first);
- }
-};
-
-}
-
-template<typename I1, typename I2>
-inline I2 copy(I1 first, I1 last, I2 out)
-{
- typedef typename
- boost::remove_cv<
- typename std::iterator_traits<I1>
- ::value_type>::type v1_t;
-
- typedef typename
- boost::remove_cv<
- typename std::iterator_traits<I2>
- ::value_type>::type v2_t;
-
- enum{ can_opt =
- boost::is_same<v1_t, v2_t>::value
- && boost::is_pointer<I1>::value
- && boost::is_pointer<I2>::value
- && boost::
- has_trivial_assign<v1_t>::value
- };
-
- return detail::copier<can_opt>::
- do_copy(first, last, out);
-}
--
© Copyright John Maddock and Steve Cleary, 2000
- - - - diff --git a/call_traits.htm b/call_traits.htm deleted file mode 100644 index 78cb60f..0000000 --- a/call_traits.htm +++ /dev/null @@ -1,754 +0,0 @@ - - - - - - -
Header
-<boost/call_traits.hpp>
-
-All of the contents of <boost/call_traits.hpp> are -defined inside namespace boost.
- -The template class call_traits<T> encapsulates the -"best" method to pass a parameter of some type T to or -from a function, and consists of a collection of typedefs defined -as in the table below. The purpose of call_traits is to ensure -that problems like "references to references" -never occur, and that parameters are passed in the most efficient -manner possible (see examples). In each -case if your existing practice is to use the type defined on the -left, then replace it with the call_traits defined type on the -right.
- -Note that for compilers that do not support either partial -specialization or member templates, no benefit will occur from -using call_traits: the call_traits defined types will always be -the same as the existing practice in this case. In addition if -only member templates and not partial template specialisation is -support by the compiler (for example Visual C++ 6) then call_traits -can not be used with array types (although it can be used to -solve the reference to reference problem).
- -Existing practice - |
- call_traits equivalent - |
- Description - |
- Notes - |
-
T |
-
|
- Defines a type that - represents the "value" of type T. Use this for - functions that return by value, or possibly for stored - values of type T. | -2 - |
-
T& |
-
|
- Defines a type that - represents a reference to type T. Use for functions that - would normally return a T&. | -1 - |
-
const T& |
-
|
- Defines a type that - represents a constant reference to type T. Use for - functions that would normally return a const T&. | -1 - |
-
const T& |
-
|
- Defines a type that - represents the "best" way to pass a parameter - of type T to a function. | -1,3 - |
-
Notes:
- --
-
- If T is already reference type, then call_traits is - defined such that references to - references do not occur (requires partial - specialization). -
- If T is an array type, then call_traits defines
value_type- as a "constant pointer to type" rather than an - "array of type" (requires partial - specialization). Note that if you are using value_type as - a stored value then this will result in storing a "constant - pointer to an array" rather than the array itself. - This may or may not be a good thing depending upon what - you actually need (in other words take care!).
- - If T is a small built in type or a pointer, then
param_type- is defined asT const, instead ofT - const&. This can improve the ability of the - compiler to optimize loops in the body of the function if - they depend upon the passed parameter, the semantics of - the passed parameter is otherwise unchanged (requires - partial specialization).
-
- -
Copy constructibility
- -The following table defines which call_traits types can always -be copy-constructed from which other types, those entries marked -with a '?' are true only if and only if T is copy constructible:
- -| - | To: - |
- ||||
| From: | -T - |
- value_type - |
- reference - |
- const_reference - |
- param_type - |
-
| T | -? - |
- ? - |
- Y - |
- Y - |
- Y - |
-
| value_type | -? - |
- ? - |
- N - |
- N - |
- Y - |
-
| reference | -? - |
- ? - |
- Y - |
- Y - |
- Y - |
-
| const_reference | -? - |
- N - |
- N - |
- Y - |
- Y - |
-
| param_type | -? - |
- ? - |
- N - |
- N - |
- Y - |
-
- -
If T is an assignable type the following assignments are -possible:
- -| - | To: - |
- ||||
| From: | -T - |
- value_type - |
- reference - |
- const_reference - |
- param_type - |
-
| T | -Y - |
- Y - |
- - - |
- - - |
- - - |
-
| value_type | -Y - |
- Y - |
- - - |
- - - |
- - - |
-
| reference | -Y - |
- Y - |
- - - |
- - - |
- - - |
-
| const_reference | -Y - |
- Y - |
- - - |
- - - |
- - - |
-
| param_type | -Y - |
- Y - |
- - - |
- - - |
- - - |
-
- -
Examples
- -The following table shows the effect that call_traits has on -various types, the table assumes that the compiler supports -partial specialization: if it doesn't then all types behave in -the same way as the entry for "myclass", and call_traits -can not be used with reference or array types.
- -| - | Call_traits type: - |
- ||||
Original type T - |
- value_type - |
- reference - |
- const_reference - |
- param_type - |
- Applies to: - |
-
myclass - |
- myclass - |
- myclass& - |
- const - myclass& - |
- myclass - const& - |
- All user - defined types. - |
-
int - |
- int - |
- int& - |
- const int& - |
- int const - |
- All small - built-in types. - |
-
int* - |
- int* - |
- int*& - |
- int*const& - |
- int* const - |
- All - pointer types. - |
-
int& - |
- int& - |
- int& - |
- const int& - |
- int& - |
- All - reference types. - |
-
const int& - |
- const int& - |
- const int& - |
- const int& - |
- const int& - |
- All - constant-references. - |
-
int[3] - |
- const int* - |
- int(&)[3] - |
- const int(&)[3] - |
- const int* - const - |
- All array - types. - |
-
const int[3] - |
- const int* - |
- const int(&)[3] - |
- const int(&)[3] - |
- const int* - const - |
- All - constant-array types. - |
-
- -
Example 1:
- -The following class is a trivial class that stores some type T -by value (see the call_traits_test.cpp -file), the aim is to illustrate how each of the available call_traits -typedefs may be used:
- -template <class T>
-struct contained
-{
- // define our typedefs first, arrays are stored by value
- // so value_type is not the same as result_type:
- typedef typename boost::call_traits<T>::param_type param_type;
- typedef typename boost::call_traits<T>::reference reference;
- typedef typename boost::call_traits<T>::const_reference const_reference;
- typedef T value_type;
- typedef typename boost::call_traits<T>::value_type result_type;
-
- // stored value:
- value_type v_;
-
- // constructors:
- contained() {}
- contained(param_type p) : v_(p){}
- // return byval:
- result_type value() { return v_; }
- // return by_ref:
- reference get() { return v_; }
- const_reference const_get()const { return v_; }
- // pass value:
- void call(param_type p){}
-
-};
-
-Example 2 (the reference to reference -problem):
- -Consider the definition of std::binder1st:
- -template <class Operation>
-class binder1st :
- public unary_function<Operation::second_argument_type, Operation::result_type>
-{
-protected:
- Operation op;
- Operation::first_argument_type value;
-public:
- binder1st(const Operation& x, const Operation::first_argument_type& y);
- Operation::result_type operator()(const Operation::second_argument_type& x) const;
-};
-
-Now consider what happens in the relatively common case that
-the functor takes its second argument as a reference, that
-implies that Operation::second_argument_type is a
-reference type, operator() will now end up taking a
-reference to a reference as an argument, and that is not
-currently legal. The solution here is to modify operator()
-to use call_traits:
Operation::result_type operator()(call_traits<Operation::second_argument_type>::param_type x) const;- -
Now in the case that Operation::second_argument_type
-is a reference type, the argument is passed as a reference, and
-the no "reference to reference" occurs.
Example 3 (the make_pair problem):
- -If we pass the name of an array as one (or both) arguments to std::make_pair,
-then template argument deduction deduces the passed parameter as
-"const reference to array of T", this also applies to
-string literals (which are really array literals). Consequently
-instead of returning a pair of pointers, it tries to return a
-pair of arrays, and since an array type is not copy-constructible
-the code fails to compile. One solution is to explicitly cast the
-arguments to make_pair to pointers, but call_traits provides a
-better (i.e. automatic) solution (and one that works safely even
-in generic code where the cast might do the wrong thing):
template <class T1, class T2>
-std::pair<
- typename boost::call_traits<T1>::value_type,
- typename boost::call_traits<T2>::value_type>
- make_pair(const T1& t1, const T2& t2)
-{
- return std::pair<
- typename boost::call_traits<T1>::value_type,
- typename boost::call_traits<T2>::value_type>(t1, t2);
-}
-
-Here, the deduced argument types will be automatically -degraded to pointers if the deduced types are arrays, similar -situations occur in the standard binders and adapters: in -principle in any function that "wraps" a temporary -whose type is deduced. Note that the function arguments to make_pair -are not expressed in terms of call_traits: doing so would prevent -template argument deduction from functioning.
- -Example 4 (optimising fill):
- -The call_traits template will "optimize" the passing -of a small built-in type as a function parameter, this mainly has -an effect when the parameter is used within a loop body. In the -following example (see algo_opt_examples.cpp), -a version of std::fill is optimized in two ways: if the type -passed is a single byte built-in type then std::memset is used to -effect the fill, otherwise a conventional C++ implemention is -used, but with the passed parameter "optimized" using -call_traits:
- -namespace detail{
-
-template <bool opt>
-struct filler
-{
- template <typename I, typename T>
- static void do_fill(I first, I last, typename boost::call_traits<T>::param_type val);
- {
- while(first != last)
- {
- *first = val;
- ++first;
- }
- }
-};
-
-template <>
-struct filler<true>
-{
- template <typename I, typename T>
- static void do_fill(I first, I last, T val)
- {
- memset(first, val, last-first);
- }
-};
-
-}
-
-template <class I, class T>
-inline void fill(I first, I last, const T& val)
-{
- enum{ can_opt = boost::is_pointer<I>::value
- && boost::is_arithmetic<T>::value
- && (sizeof(T) == 1) };
- typedef detail::filler<can_opt> filler_t;
- filler_t::template do_fill<I,T>(first, last, val);
-}
-
-Footnote: the reason that this is "optimal" for -small built-in types is that with the value passed as "T -const" instead of "const T&" the compiler is -able to tell both that the value is constant and that it is free -of aliases. With this information the compiler is able to cache -the passed value in a register, unroll the loop, or use -explicitly parallel instructions: if any of these are supported. -Exactly how much mileage you will get from this depends upon your -compiler - we could really use some accurate benchmarking -software as part of boost for cases like this.
- -Note that the function arguments to fill are not expressed in -terms of call_traits: doing so would prevent template argument -deduction from functioning. Instead fill acts as a "thin -wrapper" that is there to perform template argument -deduction, the compiler will optimise away the call to fill all -together, replacing it with the call to filler<>::do_fill, -which does use call_traits.
- -Rationale
- -The following notes are intended to briefly describe the -rational behind choices made in call_traits.
- -All user-defined types follow "existing practice" -and need no comment.
- -Small built-in types (what the standard calls fundamental -types [3.9.1]) differ from existing practice only in the param_type -typedef. In this case passing "T const" is compatible -with existing practice, but may improve performance in some cases -(see Example 4), in any case this should never -be any worse than existing practice.
- -Pointers follow the same rational as small built-in types.
- -For reference types the rational follows Example -2 - references to references are not allowed, so the call_traits -members must be defined such that these problems do not occur. -There is a proposal to modify the language such that "a -reference to a reference is a reference" (issue #106, -submitted by Bjarne Stroustrup), call_traits<T>::value_type -and call_traits<T>::param_type both provide the same effect -as that proposal, without the need for a language change (in -other words it's a workaround).
- -For array types, a function that takes an array as an argument -will degrade the array type to a pointer type: this means that -the type of the actual parameter is different from its declared -type, something that can cause endless problems in template code -that relies on the declared type of a parameter. For example:
- -template <class T>
-struct A
-{
- void foo(T t);
-};
-
-In this case if we instantiate A<int[2]> -then the declared type of the parameter passed to member function -foo is int[2], but it's actual type is const int*, if we try to -use the type T within the function body, then there is a strong -likelyhood that our code will not compile:
- -template <class T>
-void A<T>::foo(T t)
-{
- T dup(t); // doesn't compile for case that T is an array.
-}
-
-By using call_traits the degradation from array to pointer is -explicit, and the type of the parameter is the same as it's -declared type:
- -template <class T>
-struct A
-{
- void foo(call_traits<T>::value_type t);
-};
-
-template <class T>
-void A<T>::foo(call_traits<T>::value_type t)
-{
- call_traits<T>::value_type dup(t); // OK even if T is an array type.
-}
-
-For value_type (return by value), again only a pointer may be -returned, not a copy of the whole array, and again call_traits -makes the degradation explicit. The value_type member is useful -whenever an array must be explicitly degraded to a pointer - Example 3 provides the test case (Footnote: the -array specialisation for call_traits is the least well understood -of all the call_traits specialisations, if the given semantics -cause specific problems for you, or don't solve a particular -array-related problem, then I would be interested to hear about -it. Most people though will probably never need to use this -specialisation).
- -- -
Revised 01 September 2000
- -© Copyright boost.org 2000. Permission to copy, use, modify, -sell and distribute this document is granted provided this -copyright notice appears in all copies. This document is provided -"as is" without express or implied warranty, and with -no claim as to its suitability for any purpose.
- -Based on contributions by Steve Cleary, Beman Dawes, Howard -Hinnant and John Maddock.
- -Maintained by John -Maddock, the latest version of this file can be found at www.boost.org, and the boost -discussion list at www.egroups.com/list/boost.
- -.
- -- -
- - diff --git a/call_traits_test.cpp b/call_traits_test.cpp deleted file mode 100644 index 0c7155e..0000000 --- a/call_traits_test.cpp +++ /dev/null @@ -1,366 +0,0 @@ - // boost::compressed_pair test program - - // (C) Copyright John Maddock 2000. Permission to copy, use, modify, sell and - // distribute this software is granted provided this copyright notice appears - // in all copies. This software is provided "as is" without express or implied - // warranty, and with no claim as to its suitability for any purpose. - -// standalone test program for
Header
-<boost/compressed_pair.hpp>
-
-All of the contents of <boost/compressed_pair.hpp> are -defined inside namespace boost.
- -The class compressed pair is very similar to std::pair, but if -either of the template arguments are empty classes, then the -"empty member optimisation" is applied to compress the -size of the pair.
- -template <class T1, class T2>
-class compressed_pair
-{
-public:
- typedef T1 first_type;
- typedef T2 second_type;
- typedef typename call_traits<first_type>::param_type first_param_type;
- typedef typename call_traits<second_type>::param_type second_param_type;
- typedef typename call_traits<first_type>::reference first_reference;
- typedef typename call_traits<second_type>::reference second_reference;
- typedef typename call_traits<first_type>::const_reference first_const_reference;
- typedef typename call_traits<second_type>::const_reference second_const_reference;
-
- compressed_pair() : base() {}
- compressed_pair(first_param_type x, second_param_type y);
- explicit compressed_pair(first_param_type x);
- explicit compressed_pair(second_param_type y);
-
- first_reference first();
- first_const_reference first() const;
-
- second_reference second();
- second_const_reference second() const;
-
- void swap(compressed_pair& y);
-};
-
-The two members of the pair can be accessed using the member -functions first() and second(). Note that not all member -functions can be instantiated for all template parameter types. -In particular compressed_pair can be instantiated for reference -and array types, however in these cases the range of constructors -that can be used are limited. If types T1 and T2 are the same -type, then there is only one version of the single-argument -constructor, and this constructor initialises both values in the -pair to the passed value.
- -Note that compressed_pair can not be instantiated if either of -the template arguments is an enumerator type, unless there is -compiler support for boost::is_enum, or if boost::is_enum is -specialised for the enumerator type.
- -Finally, compressed_pair requires compiler support for partial -specialisation of class templates - without that support -compressed_pair behaves just like std::pair.
- -- -
Revised 08 March 2000
- -© Copyright boost.org 2000. Permission to copy, use, modify, -sell and distribute this document is granted provided this -copyright notice appears in all copies. This document is provided -"as is" without express or implied warranty, and with -no claim as to its suitability for any purpose.
- -Based on contributions by Steve Cleary, Beman Dawes, Howard -Hinnant and John Maddock.
- -Maintained by John -Maddock, the latest version of this file can be found at www.boost.org, and the boost -discussion list at www.egroups.com/list/boost.
- -- - diff --git a/compressed_pair_test.cpp b/compressed_pair_test.cpp deleted file mode 100644 index 751ab9e..0000000 --- a/compressed_pair_test.cpp +++ /dev/null @@ -1,159 +0,0 @@ - // boost::compressed_pair test program - - // (C) Copyright John Maddock 2000. Permission to copy, use, modify, sell and - // distribute this software is granted provided this copyright notice appears - // in all copies. This software is provided "as is" without express or implied - // warranty, and with no claim as to its suitability for any purpose. - -// standalone test program for