Re: Virtual Destructor - Implication & Specification
On Apr 4, 9:54 pm, "John Moeller" <fishc...@gmail.com> wrote:
On Apr 4, 6:31 pm, "Le Chaud Lapin" <jaibudu...@gmail.com> wrote:
Overloading new/delete for a class will _not_ help with the new/delete
mismatch problem in Windows, and probably other OS's. This is what I
keep saying. There are apparently expert and advance C++ programmers
who do not understand what Stroustrup wrote.
True, but it's for a specific platform and build environment.
I never said that it wasn't.
I'm going to insert a note here. I certainly don't consider myself an
expert compared to other noted contributors to this newsgroup. You
should get your information from more than one source. Why just
Stroustrup? Why not Sutter or Meyers? Both have written excellent
guides on how to take advantage of features in C++.
The information I was providing came from only one source.
I had a chance to read the section that you repeatedly cite. It's a
demonstration of why it's necessary to have a virtual destructor if
you delete through a base class pointer. That's all. It explains
what you need to do to avoid undefined behavior when deleting
polymorphically. I believe that you're taking it to mean something
more than what it says.
There is also a section in the book that claims that "proper cleanup"
for a polymorphic object would be done by virtue of virtual
destructor. I have been trying to get people to see that it is the
virtual destructor which is responsible for "proper cleanup", and not
anything else. There are some, including many programmers over the
years, who seem to think otherwise.
You're right. He never stated that providing class-specific new/
delete would help with problems that are only solved by a virtual
destructor. But he also never mentioned anything about dynamic
libraries. Additionally, you're the only one who ever mentioned
Stroustrup's book. Everyone else is trying to determine the safest
course of action for *as many platform/compiler combinations as
possible* based upon what they know of standard C++.
Now, the problem has to do with binary boundaries, and unfortunately,
the only solution (aside from a carefully-written C-only interface) is
a platform- and compiler-specific one which you have made everyone
aware of. This is why many cross-platform C++ libraries come source-
only, or the binaries are denoted with a platform and compiler.
So my job is done then. People now know that there is a platform-
specific (Microsoft Windows) means of deleting objects across binary
boundaries on Windows that does not rely on class-specific new/delete
at all.
Now, if you make the destructor virtual, that is *all* you have to do
to provide class-specific new and delete.
On one platform.
It is my opinion that making the destructor virtual is the least
painful "implementation-specific" method of achieving the desired
results.
Which will only work on a per-platform basis. Other compilers may
decide to use the new/delete solution to make the binary compatibility
work. Or they could do nothing. In which case, it would be up to the
*developer* to do what MSVC does automatically through their
implementation of deletion semantics.
I was never interested in other compiler. My goal was to explain a
mechanism.
This is the point that the rest of us are trying to get across; MSVC
is offering a helping hand in this case. It's not required that other
compilers to do the same, especially for implementation-specific
cases. You can't assume that another implementation would do the same
as MSVC just because it has made matters convenient for such a case.
I am the one who has known this for 8 years. It is others who have
refuted that my "solution" will even work on Windows, only to find out
it does. My point is that, once it is understood why it works, it
becomes clear that the reason it works is primarily because of the
virtual destructor.
In your original post, you said that you were looking for a way to
"defer to the standard" on this issue. You cannot. This has been
established because the standard says nothing about dynamic
libraries. You're more than welcome to tell your co-workers that
using a virtual destructor works to solve the heap mismatch issue when
both binaries have been compiled by MSVC (with the same options, of
course). But it would be misleading to tell them that it would work
on every platform and compiler that uses dynamic libraries.
I never said anything about other platforms. I was looking for
something in the standard that would help them see what was going on,
given that many of them were so stubborn in believing that it would
work (at previous companies especially).
One thing is certain now: one week ago, there were more than a few
who would have sworn that making the destructor virtual and doing
*nothing* else on Microsoft Windows would not have solved the new/
delete mismatch problem. And some of them have examined the assembly
language code to see that their focus should not be on class-specific
new/delete, but on the fact that the destructor is virtual.
This was my objective - to let it be shown, even if in an
implementation-specific way, the mechanism at play.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]