Boost logo

Boost :

From: Alan Griffiths (alan_at_[hidden])
Date: 1999-07-27 16:51:34

In message <v04020a00b3c2c5483805@[]>, Chelly <
ot.admi.gov_at_[hidden]> writes
>At 08:43 PM +0100 1999.07.26, Alan Griffiths wrote:
>>I too have something similar - see:
>(I fixed your URL)

Thanks. Sorry for the typo.

>An interesting property of these pointers is the shift in responsibility.
>With a shared pointer, all parties who may destroy the object must be set
>up to use one of the smart pointer types, whereas with one of these, only
>the party who needs to *know* of the deleted object needs to use a smart
> struct Foo : live_base {
> // ...
> };

Of course there is the trade off that "live_base" is incorporated into
Foo - an intrusive mechanism which limits applicability. (The
alternative of incorporating Foo into a template that aggregates it with
the live_base is less flexible than using pointer types.)

>live_ptr isn't about ownership, but about monitoring.

Both our solutions (live_ptr and uncounted_ptr) are about this, the
difference is in implementation pattern. You gain flexibility in
ownership mechanism by constraining Foo to incorporate "live_base". I
impose an ownership mechanism but remove the constraints on Foo.

You are clearly able to address a different set of problems, which means
that we are in "gut feel" territory in assessing the more general

>However, it can be
>used in similar ways - there could be multiple monitoring parties that all
>"own" the object, and when any of them delete the object, all the others

This idea feels like a risky design - unless there is some inter-owner
protocol in place then a live_ptr could become dead(?) under code that
has checked it for use. I much prefer the simplicity of "single owner"

>A variant of the live_ptr could be created that deletes the monitored
>object when it goes out of scope, if it hasn't already been deleted.

But don't return this variant from a function. :)

Alan Griffiths  (alan_at_[hidden])
ACCU Chairman   (chair_at_[hidden])   

Boost list run by bdawes at, gregod at, cpdaniel at, john at