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

On 9/02/2016 13:24, Rob Stewart wrote:

On February 8, 2016 7:10:47 PM EST, Gavin Lambert wrote:

...

...

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

...

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

On 5/02/2016 22:17, Rob Stewart wrote: that library,

...

so all's well.

That's fine, and a perfectly reasonable use of a custom deleter.

That's not what I was talking about, which was specifically limited to abuse of a null_deleter.

While I didn't mention it, I sometimes use a null deleter, in the same context, for static objects in the dynamic library.

That's more dodgy, unless the library cannot be unloaded before process exit or you can otherwise guarantee that all such shared_ptrs have been deleted prior to unloading the library. It would be better to have something that increments a library refcount as long as the shared_ptr exists, which requires either a custom deleter to decrement the refcount or some property of the object being pointed to doing the same (eg. an embedded shared_ptr to some library stand-in object -- although care needs to be taken with that to avoid cycles). This in turn means that the library can't be unloaded until all the shared_ptrs referencing it have been destroyed, including those promoted from weak_ptrs. I presume you *are* taking such care, given your description above. Again that's different from the case I was discussing.