Re: C++ Plugins and virtual destructors.

[Daniel Herring]

On Mon, 12 Nov 2007, Brendon Costa wrote:
> I can see the call of the destructor method working correctly in all
> cases. As you said it is just a virtual function call. However i was
> wondering if the memory de-allocation is performed by the child or the
> caller.

In general, memory management done by the caller.  This lets a single 
constructor/destructor work for both stack memory (local variables) and 
heap memory (~malloc/free).

> If the caller, then it is possible that the memory is allocated in the
> plugin and freed in the application. I am unsure if this could be a
> problem or not? I think it could be a problem depending on the
> implementation of the memory allocation routines for new/delete.

As long as you aren't doing anything fancy with "operator new()" and 
"operator delete()", this shouldn't be a problem.

> If for example the memory allocation/deallocation was implemented
> using a global static list of currently owned memory blocks or
> something similar, which exists once in the plugin and once in the
> application. Then we can have a problem as the plugin list will
> contain the reference for the allocated memory, but the application
> list does not and is asked to free the memory. But I dont know if this
> would ever happen?

The spot where I could see this happening is when objects are created on 
one side of the dlopen and deleted on another... and "operator new/delete" 
were customized as you mention.  Then delete could try to put things back 
in the wrong place.

Here's a relevant post from the GCC list; it mentions how to work around 
some dlopen difficulties (including RTTI, exceptions, custom new/delete).
http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html

- Daniel