Re: Virtual Destructor - Implication & Specification
On Apr 5, 6:50 am, Gerhard Menzl <clcppm-pos...@this.is.invalid>
wrote:
Le Chaud Lapin wrote:
Stroustrup never mentions EXE, DLL, or anything else related to the
Microsoft Windows platform. I don't think he even mentions dynamic
libraries in general. Not on the pages you have cited, nor anywhere else
in the book.
IIRC, There was at least one mention o dynamic linking in one of his
book. Yes this is a nit-pick, and yes, it is irrelevant to the
discussion at hand.
Chapter 15.6, "Free Store", is about a problem *introduced* by
class-specific new/delete. If you don't stop reading at page 422 and
continue to 423, you will find that Stroustrup describes two
alternatives for the static/dynamic type mismatch problem:
I am acutely aware of this fact. This is what I have been trying to
tell _other_ programmers for the past 8 years, that class-specific
delete is not a solution to the problem, it is the element that
"introduced" the problem, and the problem was solved by a virtual
destructor. I have said this online and in-person maybe 50-60 times
in the last week.
"In other words, if you want to supply an allocator/deallocator pair
that works correctly for derived classes, you must either supply a
virtual destructor in the base class *or refrain from using the size_t
argument in the deallocator*" (my emphasis)
Typical allocators, such as that popular evergreen malloc()/free(),
don't need to be told how much to deallocate, as they keep track of the
size themselves. What makes a virtual destructor absolutely necessary is
that the address passed in
delete pbase;
might have to be adjusted before being passed to operator delete, as is
most obvious when multiple inheritance is involved.
Right. So give than it is true that what happens when destructor is
virtual _is_ platform specific, my contention that, on a specific
platform, Microsoft Windows, the fact that making the destructor
virtual would solved the heap/mismatch problem should not come as a
suprised to someone who has enough experience with C++ to infer how a
compiler-writer might have implemented deletion against such an
objects. In other words, instead of emphatically refuting the idea
that the destructor being virtual solves the problems, one should
think about how they _might_ be implemented and then say,
"Hmm...ok, it is still platform-specific. I can see that, if I were
the person writing the compiler, given the possibility of the class-
specific new/delete, the ideal of reusing the destructur as callee in
more broadly-scoped destructor, etc...yes, I can see how a compiler
writer might have done that."
That is not what happens. What has happened with 100% of the people
to whom I have made the statement that the virtual destructor solves
the heap-mismatch problem on Windows is, "You are wrong, that is not
true." Then there is a small fight, and eventually these people
either see my code or right their own, and then claim, "Ok, you are
right, but you do not understand memory management in C++." It is
they who do not understand. I never had any delusions whatsoever
about what was happening, or what was defined in Stroustrup's book and
what was not. And contrary to what these people usually say, I do not
claim that making the new/delete class-specific (without exports)
solves the problem.
That Stroustrup emphasizes the - possible, not inevitable - role of a
virtual destructor in determining actual object size at all came as a
surprise to me.
I think when he wrote what he wrote, he was trying to get a point
across, but as always, he had to walk the line between providing
insight to the mechansims at play, without prescribing implementation
and hence burdening the compiler-writers, and hence said the only
thing he could have possibly said. But of course when he does this,
he is acutely aware of several possible implementations. I would
suspect that he could easily see what would become the most popular
implementation that satisfies all constraints, both implicit and
explicit.
I have always thought of this as the allocator's
business, but that merely shows I haven't been into the allocator
business a lot. The alternative, passing the size to the deallocator, is
certainly feasible. At any rate, the standard does not mandate this: the
only mandatory parameter is a void*, the pointer to the memory being
deallocated. Size is optional. (3.7.3.2).
Yes, this is true.
Now, if you make the destructor virtual, that is *all* you have to do
to provide class-specific new and delete.
I don't understand this. Virtual destructors and class-specific
operators new and delete are orthogonal. You can have one without the other.
If any of you are reading this and thinking, "Chaud's technique is
application specific and will only work on Windows..", I have news for
you: You *have* to do something that is "implementation specific" on
Windows to get this to work anyway.
It is my opinion that making the destructor virtual is the least
painful "implementation-specific" method of achieving the desired
results.
It seems to me that you are mixing up three concepts that are orthogonal
but may interact in certain, platform-specific ways: virtual
destructors, class-specific allocation/deallocation functions, and
dynamic libraries. Stroustrup wrote about the former two; nothing of it
can be taken as evidence for questions posed by the latter. On which of
several heaps an objects resides is, in principle, independent of how
big it is, and how its bytes are arranged. That virtual destructors play
a role in getting all three aspects right is coincidental and
platform-dependent. They may be necessary, but they are not guaranteed
to be sufficient for proper deallocation.
Right.
So I am back where I started. The next time I say to an advanced C++
programer,
"Making destructors virtual on Microsoft Windows will eliminate the
heap/mismatch problem",
they will probably retort, "No it won't", and then I will attempt to
explain to them the implementation-specific process that makes this
true, and try to point out two or more of the reasons why a Microsoft
engineer ***_might_*** have done it that way, including class-specific
new/delete derived problem, and they will refuse to listen, and then I
will write code and do reverse-assembly to show them that it is in
fact happening on Window, ...and they will finally see that it works
the way I said it did, and then claim that a better way is to make the
class have specific new/delete (which is patently wrong), and then I
will show that this alone is not enough, that the virtual destructor
is necessary, and they will try this, and see that, indeed, the
destructor needs to be virtual, and after all of this...they will tell
me that it is I, and not they, who did not understand what was going
on.
I would like to know a few choice words that I could say up front that
would allow us to skip past all of this non-sense.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]