Re: Virtual Destructor - Implication & Specification
On Apr 2, 3:13 pm, "h.yuz...@gmail.com" <h.yuz...@gmail.com> wrote:
Hi H.Yuzhao,
[snipped] The inside cause of
your specical instance has beyond C++ language scope, i think. I just
take a simple example as your reference. Provided you generate an EXE
file in Release build, where you allocate some size of memory on dump,
then you link a DLL which is in Debug build and try to free the memory
which allocated in the EXE. In this case, I am sure you will corrupt
the dump and get your program crashed. You can take a deep look in the
struct of memory block on dump in Debug mode and Release mode while
your are using New/Delete pair, respectively.
On the contrary: it will not crash if the destructor is virtual.
In fact, on Windows, using Visual Studio as well as several other
compilers, if the destructor is virtual, there will be no crashing.
It does not matter whether Release or Debug builds are made, or wether
the memory allocation library is statically linked with an executable
module or dynamically linked with an executable module. Once the
destructor is virtual, it will be very hard to get the program to
crash because of a heap mismatch issue.
The recommandation is that DO Not alloc/dealloc memory by new/delete
in different modules.
I agree. There has been only one occasion where I have explicitly
design my system to do mismatched new/delete accross module
boundaries. It turned out later that my entire system would have
greater structural integrity if I put all code into one EXE, so I that
is what I did, with no more problem. But there are other programmers
who routinely follow this model, manufacturing objects with new and
passing the pointer beteween modules. The technique of making the
destructor virtual is not meant to encourage these programmers, but to
provide a solution to a problem that already exists and is widespread.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]