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

Subject: Re: [boost] Severe shared_ptr limitation WRT dynamically loaded libraries
From: Jens Finkhäuser (jens_at_[hidden])
Date: 2008-11-20 08:23:49

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.
Except for horrible edge cases where between object creation and returning
the pointer something prevents you from returning the pointer, you'll
have the same results.

  Of course if you're not implementing a pure factory, but do retain
pointers to the created object within the DLL, that won't work.

Jens