[boost] Re: Re: Re: intrusive_ptr / shared_ptr.

From: Ed Brey (brey_at_[hidden])
Date: 2002-07-19 13:49:09

"Peter Dimov" <pdimov_at_[hidden]> wrote in message news:006501c22f41$3672ad20$1d00a8c0_at_pdimov2...
> 
> The difference is that the std::copy optimization doesn't affect the
> semantics; this is the as-if rule. shared_ptr's current semantics do not
> allow the optimization that you want. In order to make the optimization
> possible, you need to modify the specification.
> [...]
> 
> > > This is not an implementation detail. It affects the interface.
> >
> > I see what you are getting at, assuming your talking about the requirement
> that T be complete.  Is there no way for the decision on whether the
> compiler elides the couter pointer to be deferred until T is defined?
> <
> 
> No.
> 
> class X;
> char a[ sizeof(shared_ptr<X>) ];
> 
> For the count to be elided, you need to, at least,
> 
> * disallow the situation where an incomplete type that, in its complete
> form, derives from counted_base, is used as a template parameter for
> shared_ptr;
> 
> * disallow the construction of a shared_ptr with a custom deallocator when
> the template parameter is derived from counted_base;
> 
> * disallow the construction of a shared_ptr from a pointer to a type that is
> derived multiply from counted_base, and is therefore not convertible to
> counted_base*. :-)
> 
> There might be more issues involved.
> 
> This optimization doesn't pass my cost/benefit test, your opinion may vary.

None of these cases seem common; however, I can't say for sure they are rare enough to have an opinion that varies from yours.  If they were rare enough, I'd say put the eliding in shared_ptr, and add a template flag to turn it off when necessary.  It would certainly be nice for users or generic code to always use shared_ptr and know it is fully optimized under the hood, but not if it meant more than once in a great while remembering or getting a compiler error and remembering that a flag needed to be set.

> > > The current trend in smart pointer development is to multiply, not
> reduce,
> > > the smart pointer types by using combinatorial techniques. :-)
> >
> > A single smart pointer class that provides many types based on selection
> of orthogonal features is fine.
> <
> 
> A single class is a single type. A single class template may provide many
> types. ;-)

Details aside, the idea is that smart pointers shouldn't be like car shopping today, where you have many models that are largely the same, but you have to choose based on cost and functionality.  Instead, you'd want a single vendor that asks, "What features do you need?", and he give you a car that meets your needs a the minimal cost.  The intrusive_ptr/shared_ptr is more like the first model whereas the Loki smart pointer is more like the second.  I'm not saying that intrusive_ptr is bad, since there are a lot of issues with generative programming.  My point is that we should always actively pursue opportunities to minimize the number of smart pointer "vendors".