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

Subject: Re: [boost] Severe shared_ptr limitation WRT dynamically loaded libraries
From: J.D. Herron (jotadehace_at_[hidden])
Date: 2008-11-20 11:19:21

Thank you Jens for this suggestion.  Its a good one except for one
limitation which forces all factories to dynamically allocate raw pointers
that can be cleaned up with delete.  I would like the flexibility of the
factory to return shared_ptr so that it can use a NULL deleter to return
non-dynamically allocated objects or use their own custom deleter to allow
creation from stuff like pools.

J.D.

On Thu, Nov 20, 2008 at 6: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.
> 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
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>