Re: Virtual Destructor - Implication & Specification
On Apr 2, 6:04 pm, "Alf P. Steinbach" <a...@start.no> wrote:
* Le Chaud Lapin:
[snip]
OK, so that's what you mean by "heap mismatch problem": that the object
is allocated on one heap (e.g. in the main program), and an attempt is
made to deallocate it from another heap (e.g. in a Windows DLL).
[snip]
The in-practice: the Visual C++ compiler has supported a workaround for
the problem since and including version 5.0. It relies on using a
non-standard extension ("declspec"), plus a virtual destructor, as
you've noted; see Microsoft KB article Q122675. You can't assume that
that workaround will be implemented by other compilers.
You can instead /take control over allocation and deallocation/ via
standard C++ means.
Namely, by defining operator new and operator delete for the class in
question (you will still need a virtual destructor when destroying an
object polymorphically).
I am going to nit-pick here because there is a point that I am trying
to get across which I feel is important, as understanding it, at least
for novice C++ programmers on Windows, will provide much insight into
the interaction of the various forms of object allocation and
deallocation in C++. IOW, once this implementation-specific mechanism
is understood, much else will be understood. Of course it is not
portable, but having context on what is going on will help greatly.
There are three ways to solve the heap mismatch problem. You have
pointed out ways #1 and #2. I am going to say what #3 is in a second,
but first #1 and #2:
1. Microsoft KB article Q122675
2. Class-specific new/delete
and now the most important one in context of current dicussion..
3. Simply make the destructor virtual.
Note that #3 does not require exporting any names from the DLL, nor
does it require class-specific new/delete. Simply making the
destructor virtual will allow delete operation against any pointer to
polymorphic object in any context no matter which heap it came from
(again, implementation specific).
The reason I nit-pick on this is that there seems to be a very large
number of (advanced) C++ programmers on Windows who do not believe
this. In fact, there is a device driver writer with 22 years
experience and several in C++ who refuses to look at my demonstration
code to show him to see that it is true. From a memory management
perspective, this simple fact - virtual destructor solves all -
illuminates much about the interaction between destructors and memory
management. IMO, it is unfortunate that so many people read page
421-422 of Stroustrup TCPPPL 3rd Edition about the class-specific new/
delete, and think that class-specific definitions are necessary to
solve the problem. What I believe Stroustrup intended in the
exposition in 15.6 was to illustrate memory management for a class and
its derived classes, then expose why derived classes of such a class
might get shafted, then _use_ virtual destructors to show how to avoid
the problem. He is _not_ saying that you _must_ use class specific
new/delete to solve the shallow-destruction problem. One can also
infer this from page 319:
"We ensure proper cleanup by defining a virtual destructor
Ival_box::~Ival_box() in the base and overriding it suitably in
derived classes."
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]