RE: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>

-----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: Friday, March 12, 2004 12:24 PM To: boost@lists.boost.org Subject: Re: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
Greg Clayton wrote:
-----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: Thursday, March 11, 2004 4:48 PM To: boost@lists.boost.org Subject: Re: [boost] Explicit instantiation of boost::shared_ptr<SomeClasss>
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. 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).
Isn't it possible for the DLL C that contains the definition of SomeClass to export
shared_ptr<SomeClass> createSomeClass();
which DLL B can now call when it needs a SomeClass?
Since ~SomeClass lives in C, it must be available when the last shared_ptr<SomeClass> is destroyed.
This was my initial solution, and it does work. Though I was searching for the ability to just create a shared pointer anywhere and had it to any other DLL by exporting the entire shared pointer instantiation from the main DLL.

Greg Clayton wrote:
-----Original Message----- From: Peter Dimov
Isn't it possible for the DLL C that contains the definition of SomeClass to export
shared_ptr<SomeClass> createSomeClass();
which DLL B can now call when it needs a SomeClass?
Since ~SomeClass lives in C, it must be available when the last shared_ptr<SomeClass> is destroyed.
This was my initial solution, and it does work.
I mention it because it's the recommended approach, especially if SomeClass is most frequently allocated on the heap and used via shared_ptr<SomeClass> (there are no automatic variables of type SomeClass, and so on). Hiding the actual 'new SomeClass' behind an exported factory function makes SomeClass less error-prone, because users no longer need to use 'new' directly. You can make the constructors and the destructor of SomeClass protected to further prevent accidental mistakes. You'll also be able to change the way a SomeClass is allocated without changing one bit of code outside the DLL that hosts 'SomeClass::create' or 'createSomeClass'.
Though I was searching for the ability to just create a shared pointer anywhere and had it to any other DLL by exporting the entire shared pointer instantiation from the main DLL.
What does this buy you? Whether you export shared_ptr<SomeClass>::shared_ptr<SomeClass> or createSomeClass doesn't make much difference, and, at least in my opinion, it creates more trouble than it's worth. But I may be missing something.
participants (2)
-
Greg Clayton
-
Peter Dimov