Re: Virtual Destructor - Implication & Specification
On Apr 9, 8:30 pm, "rado" <rge...@gmail.com> wrote:
I'll try to help others in undestanding the justification of your
proposal:
Thanks.
- the presence of virtual destructor DOES cause (upon delete) using
the class-context specific deallocation function, no matter if it is
(a) class-specific delete, or (b) DLL-specific deallocation, or (c)
something else I can't yet think of. Thus, in practice, the presence
of virtual destructor ensures calling the *right* deallocation
function.
What I don't see is how it ensures calling the right *allocation*
function for the class. If a class (with virtual dtor) is defined in
DLL1, and I 'new' it from DLL2, the allocation funtion from DLL2 will
be invoked. When I 'delete' it, the deallocation function in DLL1 will
be used. Thus, we have the problem again.
Not true. The problem will be gone.
If an object is synthesized in DLL2 using new in DLL2, and the
resulting pointer is given to DLL1 from DLL2, and the destructor is
virtual, the (~) function (destructor) for the object will reside in
DLL2, and be invoked against the space for the object that was
allocated from the heap variable of DLL2. The free()'ing of the space
will occur by invoking a "free()" function in DLL2, and that function
will work against the heap variable of DLL2. There will not be a need
to use any of the Windows exporting functions. Just make the
destructor virtual. Note that making the destructor virtual, under
Windows, will generally lead to the correct tilde (~)/free sequence no
matter what was done to synthesize the object and who decided to
invoke operator delete against it. This is true by virtue of the
virtual destructor...the code that synthesizes the object and fills in
the v-table is careful to define for the destructor "slot" the correct
function to be invoked when operator delete is applied, which, in
principle, is required to acknowledge the presence of the virtual
destructor and act accordingly. Again, what it actually does is
implementation-specific, but on Windows, this is what is happening.
I see two practical solutions:
[snip]
Make the destructor virtual.
Note: if I was a compiler writer, I would do (b) by default for
exported classes with virtual destructors. Maybe MSVC does exactly
that, and that's why it works (if it does).
If I were a compiler writer, I would have implemented it pretty much
the the way it is coincidentally done on Windows, DLL's or no DLL's.
There are "other" reasons which I have purposely avoided discussing
that might lead a compiler writer to do it the way it is currently
being done.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]