"hicks"
/David Abrahams wrote:
/I think this only holds if the raw pointer is passed out of the DLL where
it
/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 scenario:
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? -Dave