|
Boost : |
From: Chelly (postmast.root.admi.gov_at_[hidden])
Date: 1999-07-26 21:21:32
At 08:43 PM +0100 1999.07.26, Alan Griffiths wrote:
>In message <v04020a01b3bede4f3570@[206.224.81.146]>, Chelly <postmast.ro
>ot.admi.gov_at_[hidden]> writes
>>At 01:43 PM -0500 1999.07.23, Andy Glew wrote:
>>>>At 03:55 PM 7/22/99 -0700, Reid Sweatman wrote:
>>>>>Anyway, I support your notion of a requested/in progress page for
>>>>>the site.
>>>
>>>I hope that nobody minds if I submit the following request?
>>>Maybe one of you can point be to existing code; or maybe
>>>I will be shamed enough to write it.
>>>
>>>Today's request: live_ptr
>>>
>>>live_ptr<T>
>>>
>>> A live_ptr is a variety of smart pointer that does not deallocate
>>> the object pointed to as long as there is a reference, etc. I.e.
>>> it is not a garbage collecting or reference counting pointer.
>>>
>>> Instead, a live_ptr points to the object as long as the object
>>>lives;
>>> when the object pointed to dies (is destroyed), then the live_ptr
>>> is set to 0.
>[snip]
>>
>>You know, this is funny, because I was working on a whole family of this
>>exact thing a few days ago. The watched object must exist before the
>
>I too have something similar - see:
>
> http://www.octopull.demon.co.uk/arglib/uncounted_ptr.html
(I fixed your URL)
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 {
// ...
};
// doesn't have to know about liveness
void f( Foo* foo ) {
auto_ptr<Foo> hold( foo ); // auto_ptr knows nothing of live_ptr
// ...
// auto_ptr deletes foo
}
void g() {
Foo* foo = new foo;
live_ptr<Foo> live_foo( foo );
f( foo );
if ( live_foo.exists() ) {
// ...
}
}
Also, the object itself can exist on the stack, since these tell if the
object was destroyed, regardless of its storage.
live_ptr isn't about ownership, but about monitoring. 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. 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk