From: Boris Fomitchev (fbp_at_[hidden])
Date: 2000-01-13 18:11:42
"greg colvin" <gcolvi-_at_[hidden]> wrote:
> > * 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
> > 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
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
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
should be used :
new (my_shared_ptr) T(.....);
Initialization frow raw pointer in general case should be banned.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk