Re: [Boost-Users] Re: MS VS 6: passing boost::shared_ptr<T> to a dll function

From: hicks (hicks_at_[hidden])
Date: 2002-06-18 23:47:09

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

Craig Hicks

David Abrahams wrote:

>"Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
>news:00fc01c21621$d3e29950$700a0c0a_at_TimeMachine...
>
>>>>>I don't know about MS, but in Borland a common source of DLL
>>>>>
>interface
>
>>>>>problems is
>>>>>not using a common (shared) memory manager.
>>>>>
>>>>Thanx Craig, that turned out to be the problem for VC++ as well.
>>>>
>>>Yep, but shared_ptr is supposed to work in this case, in theory. ;-)
>>>
>I'll
>
>>>look into this. Any more information that can help me find the problem?
>>>
>>It works if the destructor of the object being held in the shared_ptr or
>>scoped_ptr is not implemented inline in the header file. If it *is* then
>>destruction is called in the context of whoever is currently holding the
>>smart pointer to it at the time - and if that is across a dll boundary
>>
>from
>
>>the creation site then *bang* (if you have mismatched runtime models).
>>
>
>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
>
>
>
>
>
>
>Info: <http://www.boost.org>
>Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
>Unsubscribe: <mailto:boost-users-unsubscribe_at_[hidden]>
> 
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
>
>
>
>
>

[Non-text portions of this message have been removed]