|
Boost : |
From: Alan Griffiths (alan_at_[hidden])
Date: 1999-07-27 16:51:34
In message <v04020a00b3c2c5483805@[206.224.81.146]>, Chelly <postmast.ro
ot.admi.gov_at_[hidden]> writes
>At 08:43 PM +0100 1999.07.26, Alan Griffiths wrote:
>>I too have something similar - see:
>>
>> http://www.octopull.demon.co.uk/arglib/uncounted_ptr.html
>
>(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
>pointer.
>
> 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.)
[snip]
>
>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
approach.
>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
>know.
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"
model.
>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]) http://www.octopull.demon.co.uk/ ACCU Chairman (chair_at_[hidden]) http://www.accu.org/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk