Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)

Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2016-02-05 04:17:11

On February 1, 2016 8:21:19 PM EST, Gavin Lambert <gavinl_at_[hidden]> wrote:
> On 29/01/2016 23:25, Andrey Semashev wrote:
> > 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
> that
> > 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
> 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)