Re: [boost] Re: Vertical vs. Lateral Policy implementations

From: Mat Marcus (mmarcus_at_[hidden])
Date: 2002-05-17 09:46:52

--On Wednesday, May 15, 2002 1:15 PM -0500 "David B. Held" 
<dheld_at_[hidden]> wrote:

> "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.

Thanks for taking the time to comment Dave. First, let me 
reiterate that I am not at all clear whether GenVoca will yield 
the best smartptr. My main intent in posting 
<http://lists.boost.org/MailArchives/boost/msg23625.php> was to 
try to point to a solid prior theoretical foundation for 
communicating policies in the orthogonal versus communicating 
policies debate.   One of my points was that I see policy based 
design as a degenerate special case of GenVoca. A second goal 
was to consider whether the organization of a SmartPtr design 
making use of a vertical composition of refinement layers could 
be extended to yield SmartIterators. In GenVoca each vertical 
layer comprises a class category of one ore more collaborating 
(horizontal) classes which may refine the classes from the 
lower layers. It seems that it might be possible to add, say, 
an iteration refinement layer somewhere in the stack. Perhaps 
my best course is to push these ideas beyond a simple sketch in 
source code form. While I have no time for this at the moment, 
I would still like to briefly respond to a few of your 
comments. And as usual, I highly recommend C&E (ch 9.8, 12), 
who explain this much better than I.

> 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.

While some layers optional, all must fit into the stack at a 
well defined position. Ordering is important since it is not 
true that all layers can "see" each other equally. See below.

> 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.

As Dave pointed out, the essential elements of "Dave A.'s 
design" (parametrized inheritance, Coplien's 
curiously-recurring-template-pattern) are borrowed directly 
from my explanation of the GenVoca design to Dave in Curacao. I 
probably should have been more clear on the 
Coplien/Barton-and-Nackman trick in my post. I deliberately 
left configuration generators and the coplien trick out of the 
simplified diagrams in the body of the article (bad idea), 
although it can be seen in the source code at the end.  For 
example:

    > using namespace SmartPtrICCL
    > template <class T>
    > struct MySmartPtrConfig
    > {
    > // Assemble the layers
    > typedef DefaultStoredPointer<MySmartPtrConfig<T> >
    > StorageLayer;
    >
    > typedef PointerConvertible<StorageLayer>
    > OptConvertiblePointer;
    >
    > typedef AssertChecker<OptConvertiblePointer>
    > OptCheckingPointer;
    >
    > typedef RefCountedCopier<OptCheckingPointer>
    > CopyLayer;
    >
    > typedef SmartPtr<CopyLayer>
    > type;  // look here
    >
    > typedef T value_type;
    > };
    >

Here SmartPtrICCL::MySmartPtrConfig<T>::type gives all layers 
(limited) access is the complete SmartPtr type. BTW, it is 
important to note that all layers can /not/ see each other 
equally. The higher layers can completely make use of the lower 
layers. But the lower layers are limited in how much they can 
make use of the upper layers. In particular, as C&E point out, 
downward propagated types can be used as types in variable and 
function parameters but we cannot access their member types.

Mat