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@unwesen.de> wrote:
On Wed, Nov 19, 2008 at 2:37 PM, J.D. Herron <jotadehace@gmail.com> wrote:
If I have a dynamically loaded factory interface that returns a shared_ptr, the factory implementation causes the templates to generate
On Thu, Nov 20, 2008 at 05:17:56AM -0800, Emil Dotchevski wrote: 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