Re: [boost] Problem solved: EBO pessimization in smart_ptr not an issue anymore!

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-02 05:48:20

----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>

> I don't really understand how this hasn't occured to anyone yet, it's
> an
> obvious trick. I recall it occured to me at some point but then the
> synapse
> wasn't strong enough or something. Also, I saw a very similar trick,
> if not the very same trick (can't check now, I'm on a very slow
> connection) in compressed_pair.

> Now when defining smart_ptr, the policies come wrapped in
> OptionallyInherit:
>
>     template
>     <
>         typename T,
>         template <typename> class OwnershipPolicy,
>         template <typename> class ConversionPolicy,
>         template <typename> class CheckingPolicy,
>         template <typename> class StoragePolicy
>     >
>     class smart_ptr
>         : public OptionallyInherit<
>             StoragePolicy<T>,
>             OptionallyInherit<CheckingPolicy<
>                     typename StoragePolicy<T>::stored_type> >,
>                 OptionallyInherit<OwnershipPolicy<
>                         typename StoragePolicy<T>::pointer_type> >,
>                     OptionallyInherit<ConversionPolicy<
>                         typename StoragePolicy<T>::pointer_type> > > >
>     {
>         ...
>     };
>
> Doesn't look terribly intuitive, but it's library code. The client
> code stays as nice as it was. But now we got (1) orthogonal policies
> and (2) no size overhead.

Remarks:

1. Cool!

2. It does mean that the constructors/destructors of empty policies get
skipped (compressed_pair doesn't have that issue, but has others)

3. Is using public inheritance at all really important? My impression is
that you do this to allow the policies to add interface to the
smart_ptr... while at the same time you eschew public member functions.
The tack taken by the iterator_adaptors library is to expose all
possible interface in the outer template (in this case smart_ptr), and
generate compiler errors inside those functions in case of illegal
usage. The only way that could break down would be in case defining
these outer level functions changed overload resolution somehow, but I'm
under the impression that for the types of interface you're defining in
smart_ptr, that can't happen (?)

-Dave