[boost] Re: Call traits, Compressed Pair

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2000-01-17 18:05:32

scleary_at_[hidden] wrote on 1/17/2000 2:15 PM
>Howard: on your implementation of compressed_pair, I would add the ability
>to derive from both types if they're both empty, thus allowing
>compressed_pair to be an empty class as well.  (I already have some classes
>that allow up to 3 contained templated classes to be empty -- a
>compressed_pair of a compressed_pair :), and other classes that are empty if
>their contained template classes are empty).  Of course, if both types are
>the same type (watch out for cv-qualification), then we would have to
>contain one and derive from the other, like you have it now.

Metrowerks doesn't implement the empty member optimization for multiple 
inheritance.  I had assumed that this was standard behavior, but after 
glancing at the standard, I don't think it is.  Regardless I've 
__actually__ gained access to the vault! :-)  And I've uploaded 
compressed_pair.hpp to the TypeTraits directory.  I've implemented both 
of your suggestions and it should be easy to switch things around (derive 
from one, both, whatever) by playing with compressed_pair_switch (see 
code).  I haven't thoroughly tested this newly modified code so beware.

>Also, it's just personal preference, but I like to hide (in 'details'), as
>much as possible, anything that is not documented, like the default template
>parameters on compressed_pair.  For example, instead of:
>  template <class T1, class T2,
>      bool FirstEmpty  = is_empty<T1>::value,
>      bool SecondEmpty = is_empty<T2>::value>
>  class compressed_pair;
>I prefer:
>  namespace details {
>    template <class T1, class T2,
>        bool FirstEmpty  = is_empty<T1>::value,
>        bool SecondEmpty = is_empty<T2>::value>
>    class compressed_pair_helper;
>    // implementation identical to original compressed_pair
>  } // namespace details
>  template <class T1, class T2> class compressed_pair
>      : public details::compressed_pair_helper<T1, T2>
>  { ... (constructors) };
>  // OK to derive public because the base class is
>  // in 'details', which the user shouldn't use

-Howard