[boost] Re: Intrusive/invasive smart pointer?

From: Boris Fomitchev (fbp_at_[hidden])
Date: 2000-01-13 18:11:42

"greg colvin" <gcolvi-_at_[hidden]> wrote: 
original article:http://www.egroups.com/group/boost/?start=1771

> > *  Since the smart point goes in an iterator, it would be better to
> > avoid the size and separate allocation penalty of shared_ptr.
> > 
> > *  Memory allocation should use the container's Allocator.
> > 
> > *  The smart pointer needs to support construction from a raw
pointer
> > when other smart pointers to the same object are known to exist, but
> > are not available. This means there needs to be a constructor which
> > increments the reference count rather than just setting it to 1.

I do believe that, for this purpose, "reference body technique" serves
better
than invasiveness as long as you control allocation (please see
 http://www.boost.org/more/count_bdy.htm for details).

> 
> So you are using the raw pointers as weak pointers in this design?
> 
> > There are two ways I can see to deal with this:
> > 
> > 1)  General solution: add a boost::shared_in_ptr<> template to
> > boost/smart_ptr.hpp which has the same interface as
> > boost::shared_ptr<>, except for one additional constructor.
> 
> Or the old shared_ptr<T,Allocator> proposal, where the Allocator
> allocates the count as well as the T.

I think allocator should be a default parameter to shared_ptr.
Default value should be new_delete_allocator<T>, which does 
"new" to create and "delete" to delete objects, to be consistent with
auto_ptr.

As far as true invasiveness go, I would recommend :
1) determine the interface which must be supported;
2) use partial specialization of shared_ptr_traits<T> to get different
behaviour for types that support invasive counting
(using embedded release()/aquire() methods in this case).

To support allocation of T with arbitrary parameters, the following
syntax
should be used :
new (my_shared_ptr) T(.....);
Initialization frow raw pointer in general case should be banned.

-Boris.