Re: [boost] [shared_ptr] A smarter smart pointer proposal for dynamic libraries

Subject: Re: [boost] [shared_ptr] A smarter smart pointer proposal for dynamic libraries
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2008-12-24 11:28:44

On Tue, Dec 23, 2008 at 11:27 PM, J.D. Herron <jotadehace_at_[hidden]> wrote:
> On Tue, Dec 23, 2008 at 9:37 PM, Emil Dotchevski
> <emildotchevski_at_[hidden]>wrote:
>
>> As far as I can tell, the only reason your reset() appears to work is
>> that it is inlined in the executable. The compiler doesn't guarantee
>> inlining, so in general it will crash anyway.
>>
>> The solution to this problem is to inject the DLL's lifetime into any
>> shared_ptrs obtained from that DLL; that is, make the shared_ptr keep
>> the DLL afloat. This can be done easily (and non-intrusively) using
>> shared_ptr's aliasing constructor.
>
> Yes that's the point, its inlined wherever the shared pointer template is
> instantiated for the type.  Being a template it has to work that way.  Since
> that code is the same whether its instantiated in the unloaded dll or the
> executable, everything works.

The problem is that the code that maintains the refcount and releases
the object isn't a template, and so it may or may not be inlined --
that's entirely up to the compiler.

> Your solution is fine except it demands an extra burden on the architecture

It places the burden of returning a shared_ptr with correct lifetime
on the factory itself, which is another way of saying that the factory
needs to know that it deals with an unloadable module. Can this be
avoided?

The user code only deals with shared_ptr<foo> and is insulated from
knowing anything about DLLs.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode