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

From: Greg Clayton (Greg.Clayton_at_[hidden])
Date: 2004-03-15 11:59:08

> -----Original Message-----
> From: David Abrahams [mailto:dave_at_[hidden]]
> Sent: Friday, March 12, 2004 1:19 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Explicit instantiation of
> boost::shared_ptr<SomeClasss>
> 
> 
> "Greg Clayton" <Greg.Clayton_at_[hidden]> 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.

In my case I have a main DLL that is the brains of the entire app (the model is removed from the view and controller). I also have many other DLLs that are all dynamically loaded, and that can be unloaded at any time when they are no longer needed. These extra DLLs can "register" information with this main DLL, and then go away (sometimes this info is classes that are passed across DLL boundaries using shared pointers). These extra DLLs can also ask for information from the main DLL as well. The main DLL in my case never gets unloaded until the end (actually all other DLLs link to this main DLL), but all other DLLs can be unloaded.

The main issue is the virtual function table, since when you pass off ownership of the shared pointer to another DLL, the code for that vtable lives within the contributing DLL, unless you explicitly instantiate it.

I have no problem with the way shared_ptr's are currently implemented, I simply want to get them working with my program, and understand what I need to watch out and plan for.

> > 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.

That is a great idea, I will try this. 

> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
> 
> 
>