|
Boost Users : |
From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-06-17 12:10:03
> > > 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..
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