Boost logo

Boost :

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-03-06 06:58:28


jens maurer <jmaure-_at_[hidden]> wrote:
original article:http://www.egroups.com/group/boost/?start=2351
> Gavin Collings wrote:
> > As I pointed out previously, boost::shared_ptr is (or can trivially
be
> > made to be) one such 'safe to call release' pointer.
>
> The approach must be a bit more complicated than previously
> mentioned. We cannot simply set the usage count to some fixed
> value saying "don't delete", because we need to delete the
> usage count itself in the end, which is a dynamic object in the
> current shared_ptr<> implementation.

Yes, I was a little over simplistic. It would be a simple matter,
though, to OR in a boolean flag to the MSB of the use count.

> I would like
> to see code for this subjected to some performance tests.

I'm sure that can be arranged, but if there are any lessons from the
previous round of tests, it's that memory allocation and non inlining
of functions are the killers. The odd couple of instructions here and
there to test a bit flag shouldn't matter too much.

> Regarding the maintenance argument, we're basically discussing what
> kind of smart pointer (which fulfills STL container element
requirements)
> we should recommend to the average user so that there are sufficient
> options for later maintenance. For that, I would recommend some
> smart pointer with immediate notification of lost ownership to all
> members of the cooperative.

Likewise, I prefer null references to dangling ones, and prefer the
null-out-all-pointers method of release for linked_ptr. Perhaps this
is an argument in favour of linked_ptr over shared_ptr as a recommended
implementation, since we're only left with dangling references with
what I was talking about above.

Gavin.


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