[boost] Re: Vertical vs. Lateral Policy implementations

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-15 13:15:28

"Mat Marcus" <mmarcus_at_[hidden]> wrote in message
news:2097574.1021455742@[192.168.1.100]...
>
> Back in January I tried to sketch a possible a C&E GenVoca
> (Vertical layers of Lateral policies) approach to Loki smart
> pointers/smart iterators, but it didn't seem to generate much
> interest.
>
[David Abrahams]
> >> template <class Value, class Ptr = Value*>
> >> struct my_ptr
> >>     : smart_ptr<
> >>         com_refcounted<
> >>            always_non_null<
> >>               my_ptr<Value,Ptr> > > >
> >> {};

Actually, by "lateral", I mean simply multiple inheritance.  So,
the GenVoca approach seems to be strictly vertical.  Also,
the architecture you suggest in the archived message is a bit
different from what Dave A. suggests here.  In particular, your
architecture appears to have an ordering in the layers.  I do not
know if this is an explicit feature of the approach, or merely an
artifact of your particular design.  It looks to me that Dave A.
does not explicitly order the policy layers.

Frankly, the only benefit of the explicitly ordered vertical
approach that I see over the lateral approach is the elimination
of MI-EBO.  There is limited policy communication possible,
but I haven't seen a good argument for one ordering of policies
over another.  With Dave A.'s design, the recursive nature
allows all policies to see each other, which I think is a very
nice feature that I would like to explore further.  I'm not sure
why an extra layer of indirection is necessary, and it would
be interesting to see if it could be eliminated.

The formalization you introduce is interesting, but I'm not
quite sure what it brings to the table over the original lateral
design of SmartPtr.  Perhaps if you could expound on that,
we could consider its merits.

The next thing on my to-do list is implement the MI
optimizations discussed earlier, which appears to be a lot
of work to "do right".  I also want to build a non-embarrassing
set of test cases to show that the policy-based design actually
works, and on a representative set of compilers.  I also need
to take another look at some of the latest of Gennadiy's
proposals.  Finally, I would like to write some other policies
that I would find useful in some of my own projects, that might
further illustrate the utility of the policy-based design.  I hate
to talk about stuff without having actual code to look at.

At this point, I think we are more or less in the "Wild Wild
West" of smart pointer design.  Some clever people have
already forged a trail or two for us to follow, but now that
we're here, there seem to be a lot of possibilities, and not
a whole lot of "law and order", so to speak.  Even so, I like to
consider what everyone has to say on the matter, because
I really have no idea what is the best way to proceed.

If you could compare and contrast your GenVoca approach
with the original Loki pointer in some more detail (I got the
impression that the primary change was in the formalism,
and the practical change was towards a "vertical"
implementation, so correct me if I misunderstood), that would
be helpful.  It looks like your approach has the classic problem
of policy specification. ;) (Which, of course, all of the policy-
based designs suffer from)  In particular, I would like to see
concrete arguments for or against policy interaction.  I myself
have seen places where policies could interact, but it is also
possible to avoid a great deal of interaction by moving it to
the main smart pointer class (which is essentially what the
original Loki design does).

Dave