Re: [boost] Severe shared_ptr limitation WRT dynamically loaded libraries

Subject: Re: [boost] Severe shared_ptr limitation WRT dynamically loaded libraries
From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-11-20 08:37:57

On Thu, Nov 20, 2008 at 5:23 AM, Jens Finkhäuser <jens_at_[hidden]> wrote:
> On Thu, Nov 20, 2008 at 05:17:56AM -0800, Emil Dotchevski wrote:
>> On Wed, Nov 19, 2008 at 2:37 PM, J.D. Herron <jotadehace_at_[hidden]> wrote:
>> > If I have a dynamically loaded factory interface that returns a
>> > shared_ptr, the factory implementation causes the templates to generate the
>> > virtual function code within the factory library.  Everything is fine as
>> > long as the library stays loaded but if the library is unloaded, any client
>> > code holding the shared pointer to an object generated by that factory now
>> > has an invalid virtual function table for the sp_counted_base it holds.  So
>> > when the reference count goes to zero an access violation is generated.
>>
>> One solution is to "inject" the shared_ptr that would crash if a DLL
>> is unloaded with another shared_ptr that keeps the DLL afloat. I've
>> also done this with the boost::function objects that are passed to the
>> client to be used as factories.
>
>  If you're talking workarounds, here's another one: why return
> shared_ptr at all? If it's a factory you're implementing (i.e.
> something that creates objects, and doesn't hold references to them),
> there's little reason to return one.
>  Return a raw pointer, and build a shared_ptr from the return value.

Certainly, the most portable DLL interfaces would be limited to C
only. My strategy is to expand the domain of things that work across
DLL boundary just a bit over C, and include boost::shared_ptr and
boost::function in it (that is, prevent silly problems like invalid
vtbl pointers, and assume that everything else works.)

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