[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++ Plugins and virtual destructors.

From: Daniel Herring
Subject: Re: C++ Plugins and virtual destructors.
Date: Mon, 12 Nov 2007 01:46:55 -0500 (EST)

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

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).

- Daniel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]