[boost] Re: type-traits etc

From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-12-07 07:58:33

Andy -
>Isn't type traits a baby step towards a reflective
or introspective API for C++?<

No more than templates are already (or typeid is for that matter), in any
event a small feature request isn't necessarily the thin end of a wedge.

Nathan -
>It warms my heart to see the term "baggage class" resurrected as a 
term for the use of a traits class in the context where the term 
"baggage" was originally applied. <

Which was my motivation for using it, no point in inventing new terms
unnecessarily :-)

Howard -

>Yes, perhaps spell "built in type" as "fundamental type".  I'm looking at 
3.9 in the standard, and the list there looks very similar to your list.  
Might be good to stick with the same terminology (if it works).<

I was also coming to that conclusion - however there is a distinction
between those types listed in the standard, and those that are provided by
a particular compiler - for example long long, or the C99 complex types, it
seems to be reasonable to define:

is_fundamental<T>::value     - for those types listed in the standard
is_builtin<T>::value                  - for all compiler intrinsic types,
by default just a thin wrapper around is_fundamental, but forms the basis
for specialisations on other compiler supplied types.

>       template <typename T>
       struct call_traits
       {
               typedef T               value_type;
               typedef T&              reference;
               typedef const T&        const_reference;
               typedef const_reference param_type;
       };
<

Fair enough, but I think that you have more in here than just a
"call_traits", I really like Steve's idea of splitting things down into
"single-use" classes all with a common syntax - having said that the
approaches are largely orthogonal - one can be synthesised from the other.

>       template <typename T>
        struct type_traits
        {
                static const bool is_class               = __is_class(T);
                static const bool has_trivial_default    = 
__has_trivial_default_constructor(T);
                static const bool has_trivial_copy       = 
__has_trivial_copy_constructor(T);
                static const bool has_trivial_assign     = 
__has_trivial_assignment_operator(T);
                static const bool has_trivial_destructor =
__has_trivial_destructor(T);
                typedef __strip_top_level_cv(T) cv_unqualified;
        };
<

The cv-unqualified member can be generated automatically without compiler
support, however it is sometimes useful to differentiate between const and
volatile modified values: for example in a call_traits template you may
want to treat "int" and "const int" the same - passing both by value, where
as "volatile int" is better off being passed by reference - otherwise the
volatile behaviour is lost.  In the absence of compiler support, the
type_traits class can at least act as the basis for full and partial
specialisations.  It may be nice though to think of a better name -  I
appreciate that "type_traits" has precedent, but maybe "class_traits" would
be better - some other name would help to keep the class focused and avoid
calls for every newly suggested feature to be added to the one class (as
Dave pointed out a while ago).

- John.