Re: Virtual Destructor - Implication & Specification
On Apr 8, 7:42 am, fidelisde...@gmail.com wrote:
No one other than you has made said claim that I can see. You've made
the claim that someone you work with said this but unless that person
is actually posting here or you've determined some way to extrapolate
their opinion to the opinions of the rest of the C++ using population
the statement is irrelevant.
Have you been reading the thread? There is at least one contributor
to this group who did not understand that the virtual destructor, and
not class-specific new/delete, was the critical element that got rid
of both (1) undefined-behavior due to having class-specific new delete
in derived class and (2) the implementation-dependent problem that I
described originally.
Alf, obviously a member of the "C++ using population" writes:
On Apr 2, 6:04 pm, "Alf P. Steinbach" <a...@start.no> wrote:
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).
John Moeller, whom I think counts as member of the "C++ using
population":
On Apr 3, 5:50 pm, "John Moeller" <fishc...@gmail.com> wrote:
The only way to get around that is to override operator new and
operator delete in your classes, to guarantee that you call a
deallocation routine that matches your allocation routine. The
destructor isn't the same as the deallocator, and both have to be
considered. You're only considering one in your code.
Maxim, who has contributed on many occasions to C++ moderated and is
obviously a member of the "C++ using population" writes:
On Apr 4, 3:05 pm, "Maxim Yegorushkin" <maxim.yegorush...@gmail.com>
wrote:
Those functions can be overloaded operator delete/new of that class.
Standard solution and it seems that it would clearly convey the
intent. This solution has already been mention here. Is it not good
enough?
These are all expert C++ programmers. I would imagine that, for every
expert C++ programmer who had a small bit of fogginess around around
any given issues, there are N junior and M intermediate programmers
who certainly do not understand. Some of those programmers have
probably seen this thread and remained quiet. I would not be
surprised if a two or three of them actually wrote code on their own
systems to see if they were true:
In an old post, Andy Paterson wrote:
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/8b4af4ff614c33bd/20adaafab2c4bb16?lnk=gst&q=Virtually_Destructible&rnum=3&hl=en#20adaafab2c4bb16
andy.pater...@dagroupplc.com (Andy Paterson) wrote in message
<news:27f2f72a.0405021457.5ec43a66@posting.google.com>...
... I do not think is true (maybe I got the wrong end of the stick,
though). Destructors have nothing to do with memory allocation.
Then writes in a subsequent post:
Your reply is making me doubt lots of things that I thought I knew for sure
about memory allocation in DLLs, so I decided to test my assumptions. They
do indeed bear out your assertions about Virtually_Destructible.
He then goes on to explain in detail quite clearly what is going on
[naturally implementation-specific]. In fact, his explanation is the
most detailed that I have seen yet.
And of course, I imagine that if i were to CC this post to any of the
dozens of Microsoft Windows programmers who have insisted that the
virtual destructor, even in an implementation-specific way, does not
help; that some of them would respond and continue believing this
untruth.
In any case, my goal has been the same from the very beginning -
(1) get people to see that today, April 2007, it is true on Microsoft
Windows with VS 2005, that making destructor virtual will solve new/
delete heap mismatch problem
(2) gain insight to see that it is _not_ class specific new/delete
that will make all better, but the virtual destructor itself
(3) develop an intuition as to why it _might_ have been implemented by
a compiler-writer this way.
If no one had ever contested (1), even the possibility thereof, then
there would be nothing to argue about. But they do, and they will
continue to do so long after this thread has died.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]