Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-05 21:10:52

From: "Beman Dawes" <bdawes_at_[hidden]>
> At 03:58 PM 1/4/2002, David Abrahams wrote:
> >I have suggested several times that we look at the Policy Adaptor
> >used by the Iterator Adaptors Library. It certainly makes the problem of
> >policy interaction go away, since all of the policies are collected in
> one
> >place... but there have been no replies, and I am wondering why. Is it
> seen
> >as inappropriate for smart pointers? Are people having trouble
> >understanding the suggestion?
> I am. Every time you mentioned it (once in person, several other times in
> postings), I went back and read portions of the paper. In particular, the
> section below. How does it a apply to smart pointers? Smart pointers
> don't seem to have nice neat models of concepts like InputIterator,
> ForwardIterator, BidirectionalIterator, or RandomAccessIterator. Or if
> they did, there would be hundreds of them.

I don't think that really changes things much. The Policy Adaptor pattern
doesn't depend on having strictly-defined concept models any more than the
pattern used by Andrei does, AFAICT.

> I think the iterator example is
> confusing me. With smart pointers the starting point (in my mind) is a
> feature model. That translates nicely (as done by Andrei) into a set of
> policies, which are for the most part orthongonal.

The analogy with iterators is a fairly strong one. You could think of
writing an iterator library with dereference, motion, and comparison
policies, for example.

> Each of the policies
> has two or more default implementations, corresponding to the common
> feature variations for that Policy. I don't understand how to (usefully)
> mash the policies together into a single policy. I'm basically lost.

I think your nested inheritance model effectively does that, since the
SmartPtr is effectively derived from a single class which is a composition
of all of the policies:

template <
typename T,
template <class> class OwnershipPolicy,
template <class> class ConversionPolicy,
template <class> class CheckingPolicy,
template <class> class StoragePolicy >
class SmartPtr
: public ConversionPolicy <
typename OwnershipPolicy <
typename CheckingPolicy <
typename StoragePolicy<T> > > >
{ ...

A small variation might be all that's required to make it easier to build
policy interactions:

template <typename T, typename Policies>
class SmartPtr : public Policies

The Policy Adaptor pattern uses template member functions so that it isn't
neccessary to pass T as a template parameter to each of the policies.
Andrei's policies also supply types; these could be handled with nested type
generators if neccessary:

struct my_policies

    template <class T>
    struct traits
        typedef T* StoredType; // the type of the pointee_ object
        typedef T* PointerType; // type returned by operator->
        typedef T& ReferenceType; // type returned by operator*

    template <class SmartPointer>
    typename SmartPointer::ReferenceType dereference(SmartPointer const& x)
        // implementation of dereference behavior

We can supply orthogonal default policy components as follows, if desired:

struct empty {};

template <class MorePolicies = empty>
struct default_smart_ptr_storage : MorePolicies

template <class MorePolicies = empty>
struct default_smart_ptr_conversion : MorePolicies

So they can be chained together:

struct my_policies :
default_smart_ptr_storage<default_smart_ptr_conversion<> >
    // my checking and ownership policy code here

    // this allows as much interaction as desired
    // between the checking and ownership aspects

But we can also provide:

struct default_smart_ptr_policies :
                default_smart_ptr_ownership<> > > >

The Policy Adaptor pattern would encourage users to derive new policies from
default_smart_ptr_policies, replacing one element of the functionality at a
time. Typically, this approach is useful if a user is going to hand the
libarary one kind of "pointer" and request a variation on that pointer in
return (think of reverse_iterator or indirect_iterator for example).
Although it is not clear to me that this is a common need in the domain of
smart pointers (is it?), the concrete policy class may be useful for solving
the policy interaction problem.

One key difference I notice in Andrei's design is that the policies seem to
supply element's of the SmartPtr's public interface directly (e.g. op->()) .
It isn't clear to me whether this is essential or not; we should discuss it.


Boost list run by bdawes at, gregod at, cpdaniel at, john at