Re: Microsoft chooses to leave C++ compiler broken
"Edward Diener" <eldiener@tropicsoft.invalid>>
Oh, please ! Microsoft has closed with "won't fix" or "can't fix for the
current release but will re-consider in the future" every valid C++ and
C++/CLI bug I have reported to them over the last five years. For purely
C++ bugs, as opposed to C++/CLI, see:
https://connect.microsoft.com/VisualStudio/feedback/details/522094/warning-c4717-recursive-on-all-control-paths-error-erroneous
and
https://connect.microsoft.com/VisualStudio/feedback/details/344776/vc9-c-error-using-non-type-template-argument-of-member-function-pointer-defaulted-to-0
These errors are in the "nuisance" category. Compile fails, so you're
forced some workaround. The one OP mentioned is in "danger" category -- the
code compiles silently with incorrect code generation.
I won't regale anyone with all the C++/CLI bugs Microsoft has refused to
fix, but not fixing C++ bugs is the norm, not the exception, in my
experience with reporting bugs to Microsoft. Getting upset about it is a
waste of time as no amount of pressure will get Microsoft to fix a bug
they just do not want to fix.
Too bad. :(
Here's what I wrote yesterday to the ACCU list on the issue.
Just became aware of this thing, and quite out of myself. :-(
Guess everyone around here agrees the perfect symmetry of ctor/dtor calls is
fundamental in C++ and any code we write just takes it as granted.
Seems folks at M$ have different thoughts and just plant breaking bug in the
optimizer -- ant then refuse to correct it. In 2 years, then decide to not
fix it at all. To me that sounds outrageous and is ground to drop using MS
compilers. O, Murphy can't be ignored, so bugs may be in the release, but I
expect them gone after discovery. Suggesting "workaround" for the few weeks
is okay, but thinking actual programmers shall stop using locals in a
loop -- or start to count returns in functions? Hell no.
Herb Sutter already picked up the issue and promised some fix in the
followups -- but his words suggest change of heart only for the particular
issue, and reconsideration because James' example suggest more likelyness of
suspect code. Implying the system failure will remain, MS is glad to wager
with our products' correctness.
I can live with QoI issues like some code ends up in "internal compiler
error", or the optimizer bails out emitting some slow naive assembly. But
correct source, if no error is signaled and .EXE created shall have the
proper behavior. No matter what optimization is used.
I ask the community's help to find some measure to pressure vendors toward
the correct and fair behavior, that includes not even thing to leave such
defects around. Even in freebie versions, let alone paid ones.
Maybe a petition signed by many ACCU members (and other C++ users) could
create some force.
In the last decade, I several times wrote in differnt foruns addressing the
usual MS-bashing and claims about poor quality, that it mostly roots in the
90's and the company IMO changed for the right track around 2000 --
certainly the cleanup takes time but the will is there, and resources are
used for good.
Handling of this issue makes me say, I appear to have been wrong, and the
others were right. And I have to apologize too for misleading people...
----- Original Message -----
From: "James Kanze" <james.kanze@gmail.com>
Newsgroups: comp.lang.c++
Sent: Tuesday, March 16, 2010 11:39 PM
Subject: Re: Assertion vs Exception Handling
[cut for the clcm post -- see the original article see here:
http://groups.google.com/group/comp.lang.c++/msg/a657a7799d8b953d
]
The issue appears present in last SP of both VS2005 and VS2008.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]