Boost logo

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