Boost logo

Boost Users :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-19 07:27:04

"hicks" <hicks_at_[hidden]> wrote in message
> /David Abrahams wrote:
> /I think this only holds if the raw pointer is passed out of the DLL where
> /was created before the shared_ptr<> gets a chance to take ownership. The
> /cure: don't pass raw pointers around.
> /
> /-Dave
> I don't think that is correct general conclusion.

I wasn't making a general conclusion. This is about shared_ptr.

> The root of the problem is that template code in a header can be compiled
> on either side of the DLL boundary. Here is a common perfectly legal
> Class A { .... std::vector<int> vi; .... A(); ~A(); }
> Constructor and destructor are both explicit and compiled on the DLL side.
> Copy operator (operator =) is implicit and compiled on the application
(DLL client)
> side. (No explcit copy constructor.)
> Suppose a copy of an instance of "A" is made on application side.
> A a1 = a0;
> The code in vector will make allocate for the new vector using the
> client side version of new[],
> but when that object is destructed ithe same memory will be freed with
> the DLL version of delete[].
> If these two cases have differing memory managers, to be precise
> differening tables of used and
> free memory, this is illegal and will result in unpredicatable behaviour.

Have you looked carefully at the implementation of shared_ptr?


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at