Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-15 14:11:50


From: "David B. Held" <dheld_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:000e01c1fc3e$1e71c930$1d00a8c0_at_pdimov2...
> > [...]
> > I wonder... has anybody considered a design where the final smart
> > pointer is built via successive refinements, with each step being a
> > (possibly more limited, less featured) smart pointer on its own right?
>
> It sounds interesting, but could you offer a sketch of what this
> might look like? Do you mean one in which one or more policies
> are fixed, and the pointer is parameterized on the remaining policies?
> Like so:
>
> smart_ptr<T, p1, p2, p3, p4>
>
> smart_ptr_p1<T, p2, p3, p4>
>
> smart_ptr_p1_p2<T, p3, p4>
>
> Or do you mean something completely different?

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.


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