[Top][All Lists]

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

Re: C++ Plugins and virtual destructors.

From: Brendon Costa
Subject: Re: C++ Plugins and virtual destructors.
Date: Mon, 12 Nov 2007 09:30:38 +1100
User-agent: Thunderbird (Windows/20070728)

> If the vtable is functioning for normal virtual functions, why wouldn't
> it also work for a virtual destructor?  Destructors are not magic; they
> are merely functions that get called just before memory is released. 
> RTTI, a common culprit in dlopen issues, doesn't get involved here.

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. I.e.:

class Parent{ virtual ~Parent(){};};
class Child : public Parent
   std::string blah;

Parent* blah = ...;
delete blah;

The above will call the virtual destructor which will execute the
childs destructor method, and then the parents destructor. After this
the memory for the instance should be freed which is where the problem
could be.

The question is: Does the code in the child free the memory or is the
memory freed by the caller?

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.

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?


reply via email to

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