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:16:21

Thanks for your suggestion.  I've used this strategy for other things but it
just seems like an awful lot of trouble for something I would like to just
act like a raw pointer.

J.D.

On Thu, Nov 20, 2008 at 6:17 AM, Emil Dotchevski <emil_at_[hidden]>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.
>
> Another strategy which doesn't necessarily work in the case of
> shared_ptr but works for other things (like std::type_infos obtained
> from a DLL) is to use weak_ptr to detect that the DLL is gone and
> accessing the object will crash the program, and throw an exception
> instead.
>
> Emil Dotchevski
> Reverge Studios, Inc.
> http://www.revergestudios.com/reblog/index.php?n=ReCode
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>