[boost] Re: Vertical vs. Lateral Policy implementations

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-16 12:17:34

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:003e01c1fc44$5e912230$1d00a8c0_at_pdimov2...
> [...]
> What I had in mind was: I have a "basic" smart pointer, call it
> counted_ptr<T, A>. It exposes T as element_type and A as
> allocator_type. Now I want to make it throw exceptions on NULL
> dereference, so I wrap it in a checking layer:
> throw_on_null_dereference< counted_ptr<T, A> >. And
> array_access< throw_on_null_dereference< counted_ptr<T, A> > >
> would disable operator* and operator-> and provide operator[]
> instead.

So if I understand correctly, each "refinement layer" would forward
the interface of the previous layer, and add its own changes as
necessary?  So throw_on_null_dereference<> would call
counted_ptr::operator*(), but do a check first?  If I understand
correctly, this puts the main smart pointer class at the top of the
inheritance hierarchy instead of the bottom.  The interesting
feature is that it puts a whole new twist on optional policies.
The default policies are built into the basic pointer, but instead
of being the most common policies, are probably going to be
the simplest policies (no check, disallow conversion, etc.).

I guess the only issue I have with this design is the nesting penalty.
This might not be an issue, since you would hope that most calls
get inlined; but it seems like it could be a problem in some cases.
Maybe I'll try to write an implementation when I get caught up
with boost::loki::smart_ptr.

Dave