On Mar 20, 12:17 am, "Balog Pal" <p...@lib.hu> wrote:
"Edward Diener" <eldie...@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/VisualStu ... /522094/wa...
https://connect.microsoft.com/VisualStu ... /344776/vc...
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.
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...
I fully agree. As an example, Microsoft's C++ compiler does not support covariant return types with multiple inheritance and/or virtual inheritance. (I forget which.) This is in the nuisance category, especially considering that it can be worked around relatively easily. Don't get me wrong, it's annoying, but it's manageable. However, it is completely unacceptable to have a bug which results in the creation of an execution with semantics different than source without error (or warning), specifically contrary to the agreed upon standard, the C++ standard.
As a reply to Herb Sutter, even if the code required to trigger the bug was some obscure little thing (which it is not), people can still hit it in the real world. My company generates C++ code from a very limited modeling language to allow object serialization between C++, xml, and Java. Imagine what wonderful little code paths in the optimizer could result from code generation on code generation?
Short version: bogus errors and crashes can be tolerable. Non-standard behavior from compiler extensions can be tolerable. Signaling an error instead of compiling standard-compliant source can be tolerable. Producing a broken executable without error or warning from standard- compliant source is not acceptable.
PS: Balog Pal, where is this petition? I'll sign it. In the meantime I'll continue my current work which will easily allow swapping in gcc in place of visual studios to run some timing numbers on our unit / acceptance / integration tests.
PPS: Why is it that google groups shows this as apparently two random threads merged into one? Did the OP reply instead of start a new topic? Oh well. Only a minor inconvenience.
Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.
1 post • Page 1 of 1