Boost logo

Boost Users :

From: hicks (hicks_at_[hidden])
Date: 2002-06-17 20:10:33


/ Phil Nach Wrote:
/The simple solution, of course, is to put the destructor implementation in
/the implementation (cpp) file. On VC++ (and probably others), not defining a
/destructor has the same effect as defining one in the header file.
/HTH,

That would still mean that you couldn't have any STL members (not only
auto ptr but e.g., vector as well)
that could undergo a reallocation outside of the host class compiled code.
(It doesn't matter whether these members are public or not).

This is acutally quite restrictive; you have to pretty much avoid
non-const inline functions which would
lead to a size change, and some of these functions may be implicit, as
in operator =().

If you were really determined to not use a shared memory manager, I
think it would be better to go "pimple"
(pointer to implementation, as promulgated by Herb Sutter)
and hide everything in the DLL compiled file.

Cheerio

Craig Hicks

Phil Nash wrote:

>>>>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).
>
>For example - this class would exhibit the problem (well, on VC++ at least):
>
>class Awkward
>{
>public:
> Awkward(){}
> ~Awkward(){} // because the implemention (although empty) is defined here
>we get a problem
>};
>
>If you now hold a shared_ptr to an Awkward object that was created within a
>host process and pass it by shared_ptr into a sink function in a dll (ie a
>function that allows the shared_ptr to go out of scope when the ref count is
>1, thus deleting the object), then it will try to delete it from the *host
>process' heap*.
>
>At least, that is my experience.
>
>The simple solution, of course, is to put the destructor implementation in
>the implementation (cpp) file. On VC++ (and probably others), not defining a
>destructor has the same effect as defining one in the header file.
>HTH,
>
>
>[)o
>IhIL..
>
>
>
>
>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]


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net