|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-12-29 15:46:56
Bronek Kozicki wrote:
> Jonathan Turkanis <technews_at_[hidden]> wrote:
>> This question is addressed directly in the FAQ? (Q. Why doesn't
>> shared_ptr provide a release() function? )
>
> lets see FAQ answer:
>
>> A. shared_ptr cannot give away ownership unless it's unique() because
>> the other copy will still destroy the object
>
> comment 1. in my real code pointer is always unique, at the point
> where
> I want to initialize auto_ptr from it. Thus (assuming release is
> added)
> it may contain:
> if (!unique())
> throw some_exception();
>
> ... and it's OK for me.
When multiple threads are involved there is a race condition between the
unique() test and the actual release, and I'm not sure how such a feature
would interact with a lock-free implementation.
[...]
>> Furthermore, the pointer returned by release() would be difficult
>> to deallocate reliably, as the source shared_ptr could have been
>> created with a custom deleter.
>
> I do not use deleters. And if I do, I would not ask for release. Now I
> see that possibly I can simulate "release" with my own deleter (which
> will delete or not pointed object, depending on some flag) + get +
> reset. This will give me behaviour similar to 2. above. I would really
> avoid it, as it makes whole project more complicated (I would need to
> manage lifetime of deleters) and error prone.
No, you don't need to manage the lifetime of the deleter; it is managed by
shared_ptr. You only need "get_deleter<D>(px)->released_ = true;", but this
won't of course affect the pointer value of the shared_ptr copies, if they
exist.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk