On February 1, 2016 8:21:19 PM EST, Gavin Lambert
I think what Emil describes is a special case of a 'dangling_ptr' idiom, if I may call it that way. The point is that there are cases when object lifetime is controlled by a third party (e.g. the stack state, a foreign library, etc.) and you need a safe way to know when the object has been deleted. So you create a shared_ptr with a null_deleter pointing to
object and save it in that object (or another storage associated with that object). You keep only weak_ptrs to that object in all other
On 29/01/2016 23:25, Andrey Semashev wrote: that places
in the code. When you need to use the object you have to lock a weak_ptr and thus check if the object is still alive.
The thing is that there is rarely a case in practice where doing this is actually beneficial, unless you have a bit of code that *usually* deals with "real" shared_ptrs in the full shared-ownership sense and you want to exercise them in a context where you know they won't be used concurrently -- eg. unit tests.
shared_ptr can be used to manage memory differently than you imagine, it seems. I use shared_ptrs to share ownership between a plugin and the application loading it while using custom deleters to ensure that releasing the last reference means code in the dynamic library releases the memory, if indeed any was allocated. The plugin mechanism release such references before unloading a dynamic library, so all's well. ___ Rob (Sent from my portable computation engine)