Boost logo

Boost :

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

class XFactory
    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 

Boost list run by bdawes at, gregod at, cpdaniel at, john at