"Greg Clayton" <Greg.Clayton@palmsource.com> writes:
Greg Clayton wrote:
I am trying to do explicitly instantiate specific shared_ptr class for export from a Win32 DLL (currently with MSVC6, and eventually in VS2003).
First things first. Why do you need to do that? Have you tried not exporting it, have you encountered any problems?
Yes, shared pointers can't be created and handed off from DLL to DLL the way they are currently implemented.
I don't understand why people keep making this claim. As long as you don't unload DLL B, you're golden. The only other alternative prohibits unloading DLL A. I don't think that dynamically generating a fake DLL to hold the destructors would be appropriate, so IMO shared_ptr is as well-behaved as it can be wrt DLLs.
If DLL A has an STL container of shared pointers, and DLL B gets _dynamically_ loaded and adds an item to DLL A's container (creates a shared pointer to an object, and DLL B adds that shared pointer through an interface it to DLL A's STL container of shared pointers), DLL B can not be unloaded. If DLL B does get unloaded you will crash when your STL container goes out of scope (when it tries to delete the owned pointer). The virtual function table for the shared pointer lives in the DLL that creates it if you just use something like:
typedef boost::shared_ptr<SomeClass> SomeClassSP;
in a header file that comes from DLL A (for other DLLs to link to). So I need to instantiate and export everything for that shared pointer from DLL A (since it is the DLL that owns the STL containers of objects) so that the vtable stays valid for the lifetime of the shared pointer object.
Solution: pass the objects from B to A via std::auto_ptr. -- Dave Abrahams Boost Consulting www.boost-consulting.com