[boost] Re: parameter_traits aka constructor_parameter

From: Howard Hinnant (hinnant_at_[hidden])
Date: 1999-11-27 10:49:24

John Maddock wrote on 11/27/99 8:17 AM
>1) If type T is small, but expensive to copy (pimple deep copy) then the
>implementation below will produce worse code than just using "const T&", if
>necessary I can deal with this by using SGI style type_traits, to limit
>specialisation to POD types. However that may exclude some types (small
>iterators) that should be dealt with by the specialisation - take your pick
>:-)

I've been thinking about the pimpl problem too.  I think it may be the 
death of this suggestion.  This is like a huge ham in the butcher window. 
 Sure looks tasty, but when the spouse finds out how much you spent on it 
it may be your last meal.

The only way I see to save this is by following John's suggestion of the 
type_traits.

template <typename T>
struct type_traits
{
     static const bool has_trivial_copy = false;
};

template <>
struct type_traits<char>
{
     static const bool has_trivial_copy = true;
};

...

But this defeats the purpose of the IsSmall trick in the first place.  It 
still __might__ be worth it if type_traits had to be there anyway to 
support some other application.  Then we could do something like:

template< typename T, bool IsSmallAndFast = sizeof(T) <= sizeof(void*)
                                            && 
type_traits<T>::has_trivial_copy >
struct call_traits;

template< typename T >
struct call_traits< T, false>
{ ...

(haven't actually tried this to make sure it works)

And then for (small and fast) class iterators you would still have to 
specialize for type_traits, but not call_traits.  If there were some 
other benefit to type_traits, might be worth it.  But if type_traits only 
exists to support call_traits, I think not worth it.

Any chance we could get core to automate type_traits to support boost? :-)

-Howard