Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at