Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk