/ 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@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]