Boost logo

Boost :

Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-02-08 20:57:17


On 9/02/2016 13:24, Rob Stewart wrote:
> On February 8, 2016 7:10:47 PM EST, Gavin Lambert <gavinl_at_[hidden]> wrote:
>> On 5/02/2016 22:17, Rob Stewart 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
>> 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.
>>
>> 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk