Re: [boost] Loki SmartPtr study: Policy orthogonality issues

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-05 16:29:34

> I'm also concerned that the current design doesn't really support any
> feature which (like arrays) requires an interface change.

I guess that's a feature of most designs :o). Right?

You can't really really ask for magic. You can, however, ask for something
that's as close to magic as it gets :o).

> The forwarding
> functions in the SmartPtr framework class essential define the
> interface.  A   StoragePolicy, for example, could add a new form of
access,
> but there wouldn't be any way to invoke the proper CheckingPolicy function
> from it.

That's true. Also, note that oftentimes you don't want that.

> I don't think it is simplest - the lack of communication between policies
> requires more work in the SmartPointer framework itself, such as
forwarding
> functions.

I happen to think this is the proper way of doing things.

> template< class T,
>            template<class> class StorePolicy=default_store_policy,
>            template<class> class CheckPolicy=default_check_policy >
> class SamplePtr
>    : public StorePolicy<T>,
>    , public CheckPolicy<typename StorePolicy<T>::PointerType> {
>    ...
>    PointerType get() {
>      check( SP::get() );
>      return SP::get();
>      }
>    };

I find that perfectly fine. (As an aside, note that actually Loki's
smart_ptr does not have a get() member function, for a good reason.)

> Isn't the nested inheritance approach a bit simpler?  And more flexible,
> too.  Or am I missing something?

I think the nested inheritance approach is not appropriate here.

Andrei