Re: [boost] Vertical vs. Lateral Policy implementations

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-30 19:22:55

----- Original Message -----
From: "David B. Held" <dheld_at_[hidden]>
>
> Vertical policies facilitate IPC, but at a cost, depending on the
> architecture.  For instance, Beman made a tradeoff between straight
> vertical and straight horizontal policy design (diagonal policies?).
On the
> one hand, it simplified the design.  On the other hand, it fixed which
> policies could see each other.

It doesn't have to. You /can/ leave the ordering up to the user. I have
in mind a "construction kit" where you configure new smart pointers like
this:

template <class Value, class Ptr = Value*>
struct my_ptr
    : smart_ptr<
        com_refcounted<
           always_non_null<
              my_ptr<Value,Ptr> > > >
{};

Incidentally, this basic approach was suggested to me by Mat Marcus at
the C++ committee meeting; according to him it's straight GenVoca out of
C&E.

> The cost I noticed in vertical chaining is the presence of
constructors.
> All policies in the chain must provide the same set of c'tor
signatures.

Not neccessarily, but I can see how it would work out best that way.

> This is a bit annoying, as many of them don't use, say, the T* c'tor,
> but they must provide it anyway.

A small price, IMO.

> Another issue with vertical policies is that of default policies.  I
chose
> the full vertical route both to provide a wider range of
implementations
> for people to look at, and also to help test the idea of complete
> control over policy implementations by not limiting policy order.
> This, of course, makes it impossible to specify partial policy
defaults.

"Of course?" Please back up a few steps and explain for those of us who
are less sophic.

> Specifying individual defaults relies on template parameter position,
> but if any policy could end up in any position, you can't specify a
> position-dependent default.  So you are left with an all-or-nothing
> policy parameter.

I'm not sure I see this. The approach I have in mind is actually a
Policy Adapter pattern: the default policy is to dispatch to the
behavior of the underlying Ptr type.

> The only alternative I see to this is a policy mixer
> that detects missing policies, and provides defaults.  This is hardly
> a five-minute library design job.

Hearty agreement! See the iterator adaptors library for examples.

-Dave