[boost] Re: Type Traits, Take Two

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2000-01-06 12:24:22

Jeffrey D. Paquette wrote on 1/6/2000 9:20 AM
>PMFJI, I've been lurking here for a couple of months now and have been
>attempting to follow the type_traits discussion. One thing I haven't been
>able to fugure out, though, is what problem you are trying to solve with the
>type_traits class?

Moore, Paul wrote on 1/6/2000 11:59 AM
>But regardless, does it matter? Can someone give a practical problem, for
>which this sort of information is needed to provide a correct solution?
>
>While traits are a good thing, and a general traits class would be useful,
>this all smacks of a solution looking for a problem.

compressed_pair is arguably a useful utility.  It will optionally 
optimize away the space if one or the other of it's members has no data.  
compressed_pair relies on both call_traits and is_empty.

The critical characteristic of call_traits is that it be able to 
differentitate between references and non-reference types.  This is 
necessary so that if compressed_pair holds a reference as a member, you 
can get access to the referernce without creating a reference to a 
reference (which is illegal).  So call_traits depends upon is_reference 
(among a few other details).

is_empty can be elegantly implemented using something like:

template <class T>
struct can_derive_from
{
        static const bool value = is_class<T>::value || is_union<T>::value;
};

is_union is hard (impossible?) to implement without compiler support, but 
is_class is easier.  It is essentially the answer to the question:  Are 
you not an integral, and are you not a floating, and are you not a 
pointer, and are you not an array, and are you not a...?

I'm sure there are other applications, this is just an example.

-Howard