Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk