Re: [boost] [shared_ptr] A smarter smart pointer proposal for dynamiclibraries

Subject: Re: [boost] [shared_ptr] A smarter smart pointer proposal for dynamiclibraries
From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-12-25 10:01:42

J.D. Herron:

> I have a suggestion for the shared pointer implementation to overcome a
> severe limitation it has currently regarding dynamically unloaded
> libraries.  I posted a little while back regarding this problem which is
> illustrated with the following example from a Microsoft Windows
> environment.  I have a simple factory interface like so:
>
> class Factory
> {
> public:
>    virtual shared_ptr<int>  GetIntSharedPtr() = 0;
>    virtual int *                   GetIntRawPtr() = 0;
> };

...

It is indeed a limitation of shared_ptr that it doesn't work when its 
creator code is unloaded. In this respect it is similar to the following raw 
pointer code:

class X
{
    ~X();
// ...
};

class XFactory
{
public:
    virtual X * GetRawPtr() = 0;
};

in which case ~X resides in the DLL.

The advantage of the current shared_ptr code is that both the creation and 
the destruction of the pointee happen at the same place - inside the DLL. 
This allows it to support DLLs which do not use the same operator 
new/delete/malloc/free as the main executable.

The general way to solve this problem is as Emil suggests: extend the 
lifetime of the DLL so that it isn't unloaded while its code is needed.

If you just need support for ints/PODs and can guarantee that the EXE and 
the DLL agree on operator new/delete, you ought to return an auto_ptr<> from 
the factory. You can assign the auto_ptr to a shared_ptr on the client side 
and it will be deleted properly.

Returning an auto_ptr (or, in the new C++, an unique_ptr) is a way to state 
to the caller that the pointee can be delete'd from its side - which is what 
you want. A shared_ptr return implies that the creator retains the right to 
dispose of the pointee and the exact way to do so is unspecified (it can 
even retain its own shared_ptr or weak_ptr to it for some reason if the 
program logic requires). This in turn implies that the code of the creator 
must remain in memory. :-)

--
Peter Dimov
http://www.pdplayer.com