A Proposal to add Type Traits to the Standard Library

Doc. no.: J16/03-0006 = WG21/N1424
Previous Doc. no.: J16/02-0003 = WG21/N1345
Date: 03 March 2003
Project: Programming Language C++
Wiki: http://www.research.att.com/~austern/cgi-bin/wiki?TypeTraits
Reply to: John Maddock <john_maddock@compuserve.com>

Motivation
Impact on the Standard
Design
    Separate classes, or a single monolithic class?
    Are Boolean properties integral-constant expressions or types?
    Templates or intrinsic operators?
    Selection of templates
    Compiler Support
Revision History
Unresolved Issues
Proposed Text
    Requirements
    Unary Type Traits
    Relationships Between Types
    Transformations Between Type
References
Acknowledgements

I. Motivation

This proposal forms part of the "infrastructure" of the standard library; it attempts to standardize templates that are often reinvented as bespoke solutions. These templates may be used by the end user, and are often used heavily by library implementers, including those who are writing third party libraries. There are three main use cases that help explain the motivation behind this proposal:

a) Supporting the widest possible range of types

Sometimes templates are not quite as "generic" as one would wish. The problem is that not all types are created equally, implying that some categories of types may need special handling. One example of this is a version of std::pair that can hold reference types[1]. The boost compressed_pair class[2] is a more advanced example of this; as well as being able to hold reference types, it will inherit from, rather than contain, empty classes in order to take advantage of the "zero sized base class optimisation".

b) For use with static (compile time) assertions

Often there is a contract that the template parameters to a class or function must obey. Usually if the template argument does not conform to the contract then the template will fail to compile. Often in such cases the position of the error may be deep inside several layers of template code, and it is often not at all easy for the user to deduce what the problem is, and whether it is their problem or the library's. One solution proposed for this is the idea of concept-checks[3], however a simpler solution is often possible using a static assertion[4]. For example the following code uses the boost type traits library to insist that the iterator arguments have random access semantics; if an error occurs then it will be generated early on in the procedure being instantiated, and can be commented with a description of the problem:

#include <iterator>
#include <boost/static_assert.hpp> 
#include <boost/type_traits.hpp> 

template <class RandomAccessIterator > 
RandomAccessIterator foo(RandomAccessIterator from, 
                         RandomAccessIterator to) 
{ 
   // this template can only be used with 
   // random access iterators, attempting to
   // use some other iterator type will result in
   // an error message here: 
   typedef typename std::iterator_traits
           <RandomAccessIterator>::iterator_category cat; 

   typedef int this_is_a_static_assertion[
         ::boost::is_convertible<
             cat*, 
             std::random_access_iterator_tag*
         >::value ? 1 : -1]; 
   // 
   // detail goes here... 
   //
   return from; 
}

Static assertions form part of a separate proposal[10].

c) Optimising code performance.

The classic example here is the algorithm std::copy; if the types being copied are POD's, then std::memcpy can be used to copy the data, rather than a slower "object by object" copy. The boost library has one example of this approach[1]. However this is by no means the only example: the SGI standard library[7] uses a type traits mechanism to achieve the same effect, while the Dinkumware standard library uses a function overloading approach to dispatch to the correct std::copy implementation. The fact that several vendors have reinvented this technique suggests that this is an area ripe for standardisation. It should be noted that while it is easiest to give examples of traits-based optimisations from the standard library, both third party libraries and user code can (and do) make use of these techniques. In the boost libraries for example, 17 of 57 top level headers make use of boost's type traits code either directly or indirectly.

Some real world experience comes from the Metrowerks standard library, Howard Hinnant reports: "The Metrowerks "STL" makes fairly heavy use of type traits for optimization purposes, especially the traits that test for trivial member functions (e.g. has_trivial_copy). We also use add_reference extensively in <algorithm> in order to support the issues outlined in [12]"

II. Impact on the Standard

This is basically a pure extension, it does not require any modification to existing standard library headers, and does not require any core language changes. However some of the templates listed in this proposal can not be fully implemented without some help from the compiler. The proposed text does not specify how this help is provided, and as a temporary measure sufficient lattitude is granted in the proposal to ensure that it is possible to provide an implementation that conforms to the semantics given, without compiler help (see the boost reference implementation[5]). Those templates that benefit from compiler help are noted below.

III. Design

There following key design decisions to be made in this proposal:

Separate classes, or a single monolithic class?

The boost type traits library (and this proposal) uses a separate traits class for each trait, where as, for example, both Loki[6] and the SGI type traits library[7] use a single type_traits class with multiple members. There are a number of advantages to the separate traits class approach:

The library contains traits classes both to describe the properties of types, and to transform one type into another. There are also many more traits represented here than there are in competing libraries that use a single "type_traits" class (in other words a single class would be overly complex).
This approach is extensible - it is easy to add new traits classes using the methodology shown. This is particularly important for type transformations, where user defined transformations may be written to extend the library. Also new traits that describe type properties may be added by refining, combining or extending the standard traits provided by this library. In other words we define a set of concepts to which each traits class must conform.
Experience suggests that this approach is easier to maintain - some of the traits classes described here have non-trivial implementations - it is often easier to isolate the trickier cases in their own headers for ease of maintenance.
Separate traits classes allow each trait to be isolated into a separate header. This proposal splits the traits classes into three headers (<type_traits>, <type_compare> and <type_transform>), but an implementation might use more (internally), to allow selective reuse of only those parts of the type traits library that are needed for a particular class/function implementation.
Separate traits classes may be used as "compile time predicates" to metaprogramming libraries, for example with algorithms that operate on type lists[8][11].

Finally it should be noted that Loki's author has shifted away from a single type_traits class and towards separate classes in a type_traits namespace[9].

This approach contrasts with that of the current traits classes in the standard library (numeric_limits, and iterator_traits), these existing traits classes are closed for extention, where as type traits are more like an extensible concept, than a finite set of properties (as is the case for numeric_limits for example).

Are Boolean properties integral-constant expressions or types?

The boost type traits library originally used a static const bool to represent each true/false condition, where as the SGI type traits library[7] uses a type (__true_type or __false_type). The use of a type is more convenient for use with function overloading, whereas the use of an integral constant expression makes it much easier to combine traits using logical expressions - something that has been often found to be necessary during the development of the boost library. The following example shows how std::copy can be optimized by combining value based type traits:

//
// copy:
// same semantics as std::copy
// calls memcpy where appropriate.
//

namespace detail{

template <bool b>
struct copier
{
   template<typename I1, typename I2>
   static I2 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;
   return detail::copier<
         ::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

       >::do_copy(first, last, out);
}

There is one potential problem with integral constant members that should be raised however: these require an out of line definition as well as an inline initialization (but see core issues 48 and 82). If static const bool members are used, then one implementation strategy that avoids the problem of having to provide lots of definitions for these static members, would be to have the traits classes inherit from a common base class:

template <class T, T v> struct integral_constant{ static const T value = v; };
template <class T, T v> T integral_constant<T,v>::value;

typedef integral_constant<bool, true>  true_type;
typedef integral_constant<bool, false> false_type;

template <class T> struct is_void : public false_type {};
template <> struct is_void<void> : public true_type {};
// etc

Note that there is no requirement to implement the traits classes in this manner: an enum could be used here in place of a static const bool. This scheme does however make it trivial to select a function overload based on whether a traits class inherits from true_type or false_type.

An important use case for providing a type representation for the result of Boolean traits comes from the template metaprogramming, the discipline where class templates are treated as compile-time invocable entities (metafunctions), and where experience has shown that to build a consistent and coherent framework of well-interpolating components it's crucially important for the metafunctions to provide a single common form of invocation [11]. Since it is possible to wrap an integral constant in a type, but not vice-versa, the implementation of boost type traits library was re-written to provide the result of Boolean trait templates through both their static const bool value member and the nested type typedef exposing the corresponding specialization of an integral constant type wrapper.

This proposal follows the boost traits library approach; the template and typedefs:

template <class T, T v> integral_constant;
typedef integral_constant<bool, true> true_type;
typedef integral_constant<bool, false> false_type;

have been added to act as type-based aliases for integral constant expressions. Likewise the type_traits requirements and descriptions have been updated to make use of this helper template, for example:

template <class T> struct is_void{
  static const bool value = implementation defined;
  typedef bool value_type;
  typedef integral_constant<value_type, value> type;
};

This gives us the best of both worlds, allowing the programmer to use either a type or a value depending upon whichever is the most convenient. For example the std::copy example could be implemented as follows:

template<typename T>
T* do_copy(const T* first, const T* last, T* out, const true_type&)
{ /* optimised copy here */ }

template<typename I1, typename I2, bool b>
I2 do_copy(I1 first, I1 last, I2 out, const integral_const<bool,b>&)
{ /* non-optimised copy here */ }

template<typename I1, typename I2>
inline I2 copy(I1 first, I1 last, I2 out)
{
   typedef typename std::iterator_traits<I1>::value_type value_type;
   typedef typename has_trivial_assign<value_type>::type trivial_assign;
   return do_copy(first, last, out, trivial_assign());
}

This example can be simplified even further if we insist that for each trait X, then X is implicitly convertible to X::type: this can be accomplished in one of two ways: by inheritance from a common base class (as above), or by providing a member conversion operator:

template <class T> struct is_void{
  static const bool value = implementation defined;
  typedef bool value_type;
  typedef integral_constant<value_type, value> type;
  operator type()const;
};

This proposal does not specify which method should be used, but it does specify that the conversion is possible; even though this is merely a convenience it is nonetheless a useful one. The std::copy example can now be simplified further still:

template<typename T>
T* do_copy(const T* first, const T* last, T* out, const true_type&)
{ /* optimised copy here */ }

template<typename I1, typename I2, bool b>
I2 do_copy(I1 first, I1 last, I2 out, const integral_constant<bool,b>&)
{ /* non-optimised copy here */ }

template<typename I1, typename I2>
inline I2 copy(I1 first, I1 last, I2 out)
{
   typedef typename std::iterator_traits<I1>::value_type value_type;
   return do_copy(first, last, out, has_trivial_assign<value_type>());
}

Templates or intrinsic operators?

There has been some fairly intense discussion on boost mailing list about the is_convertible template, one suggestion was that since only expressions (and not types) are convertible to a type or not, that is_convertible should be an intrinsic binary operator whose first argument was an expression, and whose second was a type. There are two key advantages to this approach: it more closely mirrors the text of the standard, and therefore standard wording is easier to formulate, and the result can be context sensitive:

class B;
class A
{
    A(const B&);
    /* details omitted */
};

Here class B is convertible to A only within the scope of A; if is_convertible is a template then the one definition rule requires that is_convertible<B,A>::value have one value only, and must not be sensitive to context.

On the other hand, inspite of its failings, the is_convertible template has proven to be extremely useful in practice, and only very rarely does a corner case arise where it fails to do the right thing. The template also appears to be easily understood by end users, even if getting the standardese correct is tricky. To put this in perspective there are about 50 uses of the is_convertible template within the boost library, and none of these would obviously benefit from an operator style of syntax, some examples include:

lexical_cast: uses is_convertible to determine whether the source type can be implicitly converted to the destination type, if it can then the usual iostream based cast is optimised away.
Named template parameters: several libraries use is_convertible to determine whether a template parameter is a particular named parameter, otherwise the parameter is treated as a positional parameter.
Higher level traits: is_convertible is often used to help compose higher level traits classes; for example the lambda library uses this to calculate type promotions. However this functionality could probably be more easily implemented with a typeof operator.
Static assertions: several libraries use is_convertible in conjunction with static assertions to verify that template arguments have the required properties, and to output an early, well commented error message if they do not.

Likewise is_convertible has been used (outside of boost) to ensure that code "does the right thing", for example the constructor:

template <class T, class Allocator>
template <class I>
vector<T,Allocator>::vector<I>(I first, I last, const Allocator& a);

Needs to behave differently depending upon whether type I is an iterator or a numeric type. One solution is to default initialise the object, and then perform a compiler time dispatch to different a member function depending upon whether the expression:

is_convertible<I,size_type>::value && is_convertible<I,value_type>::value

is true or not.

The author's belief is that as far as the DR is concerned, the is_convertible template class is the right way to go; it is better understood, and has shown itself to be useful as compared to an as yet untried intrinsic operator. It also fits well into the current type traits conceptual framework. However, implementers should be encouraged to experiment with an intrinsic convertibility operator, and this subject may need to be revisited prior to the next standard.

Instantiation of template arguments

There have been requests from the authors of boost’s MPL that the proposal document whether instantiation any of the unary traits class templates in this proposal will result in the instantiation of a template argument that is itself a template-id (there are some metaprogramming idioms [11] where it is important that instantiation does not occur). Section (14.7.1) implies that if it is a precondition that the a template argument be a complete type (because the semantics of the class depend upon it), then instantiation of that argument (if it is a template-id) is essential in order to determine whether the type has a specific property or not. Similary, for those class templates that do not mandate that the template argument(s) are complete types, there are nonetheless implementations that may require that the type is a complete type (for example is_enum and any other templates that rely upon it). Therefore, mandating that these templates work with incomplete types or with template-id’s which can not be instantiated, results in compiler support being required where it was not required before. Nonetheless MPL's authors believe that this is a sufficiently important problem that some wording requiring traits class templates not to instantiate their template arguments has been added, albeit with latitude permitting instantiation to occur as a temporary workaround until such time as compiler support becomes available.

Selection of templates

Perhaps the most difficult part of this proposal is deciding which traits classes should be included. The boost type traits library has undergone several revisions, with some templates being removed and others added. This proposal includes most of the current boost type traits classes along with a small number of others that are motivated by Loki[6].

Several templates that were in the original proposal were removed after feedback from the LWG (add_const, add_volatile, add_cv, add_pointer, add_reference). These were then reinstated after strong complaints from some of boost's users. The rationale is that these templates are all used as compile time functors which transform one type to another, for example Aleksey Gurtovoy provides the following example, which uses the boost metaprogramming library[11] to transform one type list to another, using type traits as compile time functors:

// transforms 'tuple<T1,T2,..,Tn>'
// to 'tuple<T1 const&,T2 const&,..,Tn const&>'
template< typename Tuple >
struct tuple_of_refs
{
   // transform tuple element types
   typedef typename mpl::transform<
      typename Tuple::elements,
      add_reference< add_const<_1> > // here!
   >::type refs;
   typedef typename tuple_from_sequence<refs>::type type;
};

template< typename Tuple >
typename tuple_of_refs<Tuple>::type
tuple_ref(Tuple const& t)
{
    return typename tuple_of_refs<Tuple>::type(t);
}

Although such uses have been rare up until now, they are becoming much more common, especially with the introduction of metaprogramming frameworks such as boost's MPL. In this context these templates are analogous to those in <functional>, in both cases the implementations are trivial, but unless these are provided in the standard library, users will have to constantly reinvent the same solution. Provision of these templates also allows for compiler warning suppression in a portable manner:

template <class T>
class foo
{
    // The following declaration does not produce a
    // warning if T is already const, or is a reference type:
    typedef typename std::add_const<T>::type type; 
    /* details omitted */
};

Feedback from the LWG suggested renaming "is_same" to "is_identical", however there was strong feeling among the boost community for retaining is_same, therefore no change has been made.

There have been three late additions to this proposal:

template <class T> struct is_signed;
template <class T> struct is_unsigned;
template <class T> struct is_abstract;

These additions may need reviewing as the proposal progresses - although no great problems are anticipated from them - in particular is_signed and is_unsigned have been part of the Metrowerks type traits library for some time. There have been some fairly persistent requests for the addition of these three templates to boost, and they are likely to added soon.

There have been one or two requests that haven't made it into the proposed text, mainly because these are templates that either don't sit well in the current design structure, or because their usefulness isn't clear. These are documented here in case the committee wants to discuss and/or add these to the text.

From Dave Abrahams:

"Here's another one we need:

has_common_base_class<T,U>::value

This is the one which allows us to explicitly construct empty classes on top of one another. I suppose you could argue that the compiler should just do this automatically with the empty base optimization, but the ABIs of many compilers are now fixed and they will never (for practical purposes) be able to do it."

From Andrei Alexandrescu:

"An important trait that's missing is the transformation same_align_pod, which would yield a POD type with the same alignment requirements as the passed-in type. This type would allow one to build a union that obeys specific alignment requirements."

Compiler Support

The following templates require compiler support for a fully conforming implementation:

template <class T> struct is_class;
template <class T> struct is_union;
template <class T> struct is_enum;
template <class T> struct is_polymorphic;
template <class T> struct is_empty;
template <class T> struct has_trivial_constructor;
template <class T> struct has_trivial_copy;
template <class T> struct has_trivial_assign;
template <class T> struct has_trivial_destructor;
template <class T> struct has_nothrow_constructor;
template <class T> struct has_nothrow_copy;
template <class T> struct has_nothrow_assign;
template <class T> struct is_pod;
template <class T> struct is_abstract;

In all of these cases however, a nearly-conforming implementation can be provided without any compiler support (see the boost reference implementation [5]), in addition temporary latitude is provided in the proposed TR text to permit a library-only implementation (see implementation requirements).

This text does not specify how the compiler support is provided, and nor will it do so, as the author believes that this is over-specification. There are multiple methods for providing this support, the relative merits of which probably depend most upon the compiler's internal structure. To put this in perspective, library vendors will need to do only a small amount of library configuration if they need to support multiple compilers, where as specifying the method used would entail duplicating a large portion of the existing descriptions in this text, increasing the maintenance cost, and the likelihood of defects.

To date three vendors provide some degree of compiler type traits support:

SGI's compiler will automatically generate specialisations for their __type_traits class, allowing for full implementations of is_pod, has_trivial_constructor, has_trivial_copy, has_trivial_assign and has_trivial_destructor.
Metrowerks' compiler supports is_enum, is_union, is_function, is_class, has_trivial_copy, has_trivial_assign and has_trivial_destructor. Howard Hinnant reports that adding support has been straightforward using builtin operators such as __builtin_type, and that using builtin operators is an order of magnitude faster than using a more complex but portable library-only solution. Metrowerks' report that they are continuing to add new builtin operators as and when their standard library can make some use of them.
Gabriel Dos Reis and Phil Edwards, both have experimental intrinsic type traits implementations in the gcc compiler. Gabriel reports that these use simple builtin operators, such as __is_scalar(T), which evaluates to an integral constant depending upon the type T. Phil Edwards reports that these mostly require very simple one-line implementations; these facilities will form part of an official gcc development-branch shortly.

IV Revision History

Added comparison to numeric_limits and iterator traits design.

Added discussion on is_convertible.

Rewritten the compiler support section: added comments on existing implementations.

Allow implementation of integral members as integral constant expressions, not necessarily as static const bool's.

Added section on implementation variance to permit a conforming implementation within the current language.

Clarified language on use of T and cv-qualified T.

Removed permission for user defined specialisations of type categories.

is_float renamed is_floating_point.

is_member_pointer demoted to a composite type category; added is_member_object_pointer and is_member_function_pointer to the primary type category traits.

Removed all the author's explanitory notes.

Simplified definition of is_compound.

Renamed has_nothrow_construct has_nothrow_constructor for consistency with has_trivial_constructor.

Rewritten definition of non-throwing text, may still not be quite right.

Renamed is_base_and_derived to is_base_of: this change has caused a fair amout of controversy, with many boosters prefering the more verbose original name.

Renamed is_POD to is_pod for consistency with other all-lower-case names.

Added additional members type, value_type and operator type, to Unary and binary type traits.

Added the new templates is_unsigned, is_signed and is_abstract.

Added section(s) on template class instantiation.

V Unresolved issues

It is unclear what the name of is_base_of should be: this is called is_base_and_derived in the boost library - the intent is that the name is so explicit that the user can't get the template parameters the wrong way around - likewise it is easier on users reading someone else's code. However there is no getting around the fact that this is an extremely verbose name, so perhaps is_base_of is a better choice.

Is is unclear how remove_pointer should behave with pointers to member (functions). Since there are no such types as "member" or "member function returning type" (you can't dereference member pointers for example), the current version is logical in leaving member pointers unchanged. However one boost user has requested that remove_pointer<T (U::*)>::type evaluates to T, on the grounds that this transformation is sometimes useful.

It is unclear whether the newly added template is_abstract requires compiler support or not, to be on the safe side it is listed as requiring support, but this may be removed at a later date.

Proposed Text

Type Library

This clause describes components used by C++ programs, particularly in templates, to: support the widest possible range of types, optimise template code usage, and detect type related user errors.

The type library provides three facilities: access to the properties of a particular type, access to the relationships (if any) between two types, and transformations from one type to another; as summarised in table TT1

Table TT1 - Type Library Summary

Clause	Header
Requirements
Unary type traits	<type_traits>
Relationships between types	<type_compare>
Transformations between types	<type_transform>

TT.1 Requirements

TT.1.1 Unary Type Traits

In table TT2, X is a class template that is a unary type trait and T is any arbitrary type.

Table TT2 - UnaryTypeTrait requirements

Expression	Return type	Requirement
X<T>::value	bool	An integral constant expression that is true if T has the specified trait, and false otherwise.
X<T>::value_type	bool	A type that is the type of X<T>::value, this is always bool for UnaryTypeTraits.
X<T>::type	integral_constant<bool,value>	A type for use in situations where a typename is more appropriate than a value. The class template integral_constant is declared in <type_traits>.
X<T>::type t = X<T>()		Both lvalues of `type X<T> const&` and rvalues of type `X<T>` are implicitly convertible to `X<T>::type`.

TT.1.2 Binary Type Traits

In table TT3, X is a class template that is a binary type trait and T and U are any arbitrary types.

Table TT3 - BinaryTypeTrait requirements

Expression	Return type	Requirement
X<T,U>::value	bool	An integral constant expression that is true if T is related to U by the relation specified, and false otherwise.
X<T,U>::value_type	bool	A type that is the type of X<T,U>::value, this is always bool for BinaryTypeTraits.
X<T,U>::type	integral_constant<bool,value>	A type for use in situations where a typename is more appropriate than a value. The class template integral_constant is declared in <type_traits>.
X<T,U>::type t = X<T,U>()		Both lvalues of type `X<T,U> const&` and rvalues of type `X<T,U>` are implicitly convertible to `X<T,U>::type`.

TT.1.3 Transformation Traits

In table TT4, X is a class template that is a transformation trait and T is any arbitrary type.

Table TT4 - TransformationTrait requirements

Expression	Requirement
X<T>::type	The result is a type that is the result of applying transformation X to type T.

TT.2 Unary Type Traits

This sub-clause contains templates that may be used to query the properties of a type at compile time.

All of the class templates defined in this header satisfy the UnaryTypeTrait requirements.

For all of the class templates declared in this clause, all members declared static const shall be defined in such a way that they are usable as integral constant expressions.

For all of the class templates X declared in this clause, both rvalues of type X const and lvalues of type X const& shall be implicitly convertible to X::type. Whether this is accomplished by inheritance or by a member operator is unspecified. For exposition only the class templates in this clause are shown with a member conversion operator:

operator type() const;

which shall return type() in all cases.

For all of the class templates X declared in this clause, instantiating that template with a template-argument that is a class template specialization, may result in the implicit instantiation of the template argument if and only if the semantics of X require that the argument must be a complete type.

TT.2.1 Header <type_traits> synopsis

namespace std{

// helper class:
template <class T, T v> struct integral_constant;
typedef integral_constant<bool, true> true_type;
typedef integral_constant<bool, false> false_type;

// Primary type categories:
template <class T> struct is_void;
template <class T> struct is_integral;
template <class T> struct is_floating_point;
template <class T> struct is_array;
template <class T> struct is_pointer;
template <class T> struct is_reference;
template <class T> struct is_member_object_pointer;
template <class T> struct is_member_function_pointer; 
template <class T> struct is_enum;
template <class T> struct is_union;
template <class T> struct is_class;
template <class T> struct is_function;

// composite type categories: 
template <class T> struct is_arithmetic;
template <class T> struct is_fundamental;
template <class T> struct is_object;
template <class T> struct is_scalar;
template <class T> struct is_compound;
template <class T> struct is_member_pointer;

// type properties:
template <class T> struct is_const;
template <class T> struct is_volatile;
template <class T> struct is_pod;
template <class T> struct is_empty;
template <class T> struct is_polymorphic;
template <class T> struct is_abstract;
template <class T> struct has_trivial_constructor;
template <class T> struct has_trivial_copy;
template <class T> struct has_trivial_assign;
template <class T> struct has_trivial_destructor;
template <class T> struct has_nothrow_constructor;
template <class T> struct has_nothrow_copy;
template <class T> struct has_nothrow_assign;
template <class T> struct is_signed;
template <class T> struct is_unsigned;

} // namespace std

TT.2.2 Helper classes

template <class T, T v> 
struct integral_constant
{
   static  const T                value = v;
   typedef T                      value_type;
   typedef integral_constant<T,v> type;
};
typedef integral_constant<bool, true> true_type;
typedef integral_constant<bool, false> false_type;

The class template integral_constant and its associated typedefs true_type and false_type are for use in situations where a type rather than a value is required.

TT.2.3 Primary Type Categories

The primary type categories correspond to the descriptions given in section 3.9.

For any given type T, exactly one of the primary type categories shall have its member value evaluate to true.

For any given type T, the result of applying one of these templates to T, and to cv-qualified T shall yield the same result.

Undefined behaviour results if any C++ program adds specializations for any of the class templates defined in this clause.

template <class T> struct is_void {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is void or a cv-qualified void. Otherwise defined to be false.

template <class T> struct is_integral {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is an integral type (3.9.1). Otherwise defined to be false.

template <class T> struct is_floating_point {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a floating point type (3.9.1). Otherwise defined to be false.

template <class T> struct is_array {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is an array type (3.9.2). Otherwise defined to be false.

template <class T> struct is_pointer {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a pointer type (3.9.2), this includes all function pointer types, but not pointers to members or member functions. Otherwise defined to be false.

template <class T> struct is_reference {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a reference type (3.9.2), this includes all reference to function types. Otherwise defined to be false.

template <class T> struct is_member_object_pointer {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a pointer to a data member. Otherwise defined to be false.

template <class T> struct is_member_function_pointer {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a pointer to a member function. Otherwise defined to be false.

template <class T> struct is_enum {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is an enumeration type (3.9.2). Otherwise defined to be false.

template <class T> struct is_union {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a union type (3.9.2). Otherwise defined to be false.

template <class T> struct is_class {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a class type (3.9.2), in this context unions are not considered to be class types. Otherwise defined to be false.

template <class T> struct is_function {
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a function type (3.9.2). Otherwise defined to be false.

TT.2.4 Composite type traits

These templates provide convenient compositions of the primary type categories, corresponding to the descriptions given in section 3.9.

For any given type T, the result of applying one of these templates to T, and to cv-qualified T shall yield the same result.

Undefined behaviour results if any C++ program adds specializations for any of the class templates defined in this clause.

template <class T> struct is_arithmetic { 
   static const bool value = is_integral<T>::value || is_floating_point<T>::value; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is an arithmetic type (3.9.1). Otherwise defined to be false.

template <class T> struct is_fundamental{
   static const bool value = 
      is_integral<T>::value 
      || is_floating_point<T>::value 
      || is_void<T>::value; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a fundamental type (3.9.1). Otherwise defined to be false.

template <class T> struct is_object{
   static const bool value = 
      !(is_function<T>::value 
         || is_reference<T>::value 
         || is_void<T>::value); 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is an object type (3.9). Otherwise defined to be false.

template <class T> struct is_scalar{
   static const bool value = 
      is_arithmetic<T>::value 
      || is_enum<T>::value
      || is_pointer<T>::value 
      || is_member_pointer<T>::value; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a scalar type (3.9). Otherwise defined to be false.

template <class T> struct is_compound{
   static const bool value = !is_fundamental<T>::value; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a compound type (3.9.2). Otherwise defined to be false.

template <class T> struct is_member_pointer {
   static const bool value = 
       is_member_object_pointer<T>::value
       || is_member_function_pointer<T>::value; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is a pointer to a member or member function. Otherwise defined to be false.

TT.2.5 Type properties

These templates provide access to some of the more important properties of types; they reveal information which is available to the compiler, but which would not otherwise be detectable in C++ code.

Except where specified, it is undefined whether any of these templates have any full or partial specialisations defined. It is permitted for the user to specialise any of these templates on a user-defined type, provided the semantics of the specialisation match those given for the template in its description.

template <class T> struct is_const{
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is const-qualified (3.9.3). Otherwise defined to be false.

template <class T> struct is_volatile{
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};

value: defined to be true if T is volatile-qualified (3.9.3). Otherwise defined to be false.

template <class T> struct is_pod{
   static  const bool value                    = implementation_defined; 
   typedef bool                                value_type;
   typedef integral_constant<value_type,value> type;
   operator type()const;
};