Re: [boost] shared_ptr changes

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-24 11:10:08

Perhaps this has been discussed already, but it seems to me that
intrusiveness could possibly be shoved into shared_ptr<T>. The outline
of my idea:

1. Use traits to discover whether a type has an embedded reference count
and what its type is. The default implementation of the traits use the
access call get_shared_count(p) to determine whether the count is
embedded. We provide char (& get_shared_count(...) )[MAX_ULONG] to help
us distinguish when it's not implemented.

2. The default deleter function generated for a shared_ptr which does
not have an internal count is responsible fro deleting the count object
as well

3. The deleter function generated for a shared_ptr to an object with an
internal count obviously doesn't do that.

-Dave

----- Original Message -----
From: "Darin Adler" <darin_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, April 24, 2002 9:51 AM
Subject: Re: [boost] shared_ptr changes

>
> On Wednesday, April 24, 2002, at 03:23 AM, Peter Dimov wrote:
>
> > I'm still undecided about the case where Y is derived from
> > counted_base. The
> > current behavior doesn't detect this and allocates an external
reference
> > count; having two separate reference counts for the same object is
> > almost
> > always a mistake.
> >
> > On the other hand, making the constructor autodetect is a semantic
> > overload
> > (a single function with multiple behaviors) which is typically to be
> > avoided
> > (it breaks the use_count() == 1 postcondition in some cases.)
>
> One possibility is to overload for the counted_base case and make it
an
> error to construct a shared_ptr from one of these objects. You could
> explicitly construct an intrusive_ptr if you were doing it
intentionally.
>
>      -- Darin
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost