I will follow up soon, there are some interesting issues here. But
On Sun, 12 Aug 2007 00:18:37 GMT, Dan Bloomquist <public21@lakeweb.com>
wrote:
Thanks Doug,
You made it easier to figure out and I learned something important about
the heap(s).
By putting:
XMLNODESET::~XMLNODESET( )
{
}
in the dll instead of just:
~XMLNODESET( ){ }
in the header, it forces destruction in the dll's heap and now it works.
Glad you got it to work. I'd still feel a little uneasy sharing C++ classes
that contain things like std::vectors between modules, when all the modules
aren't linking to the same CRT DLL. I'd at least want the class to use the
handle/body idiom, like this:
class X_EXPORT XMLNODESET
{
private:
class Impl;
public:
// Function declarations, nothing inline.
// All functions potentially generated by the compiler must be
// accounted for...
XMLNODESET();
~XMLNODESET();
void f();
private:
// Copyguard
//
// Here are the other two potentially compiler-generated functions.
// These are declared but never defined to rule out copying. If you
// want to support copying, move them to the public section and
// implement them.
XMLNODESET(const XMLNODESET&);
void operator=(const XMLNODESET&);
private: // Data section
Impl* p_impl;
};
Then in the DLL, it would be defined like this:
class XMLNODESET::Impl
{
public:
void f() {}
private:
std::vector<int> v;
};
void XMLNODESET::f()
{
p_impl->f();
}
This way, everything XMLNODESET objects do is done in the DLL, and
compilation dependencies have been minimized. In particular, all the
std::vector code is instantiated in the DLL, rather than some of it being
duplicated in the EXE, which would happen if XMLNODESET had inline
functions that used the vector. Note that if you're using different heaps,
you still have to worry about creating and deleting XMLNODESET objects in
the same context. (This is mitigated if XMLNODESET has a virtual dtor, and
X_EXPORT is __declspec(dllexport|dllimport) in the proper way, but this is
obscure, and I wouldn't rely on it.)