Boost logo

Boost :

From: Greg Clayton (Greg.Clayton_at_[hidden])
Date: 2004-03-15 12:01:42


> -----Original Message-----
> From: Peter Dimov [mailto:pdimov_at_[hidden]]
> Sent: Friday, March 12, 2004 12:24 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Explicit instantiation of
> boost::shared_ptr<SomeClasss>
>
>
> Greg Clayton wrote:
> >> -----Original Message-----
> >> From: Peter Dimov [mailto:pdimov_at_[hidden]]
> >> Sent: Thursday, March 11, 2004 4:48 PM
> >> To: boost_at_[hidden]
> >> 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk