Prev: o.k. to use boolean expression as array index?
Next: linktime error for function overloads in template class when library is a dynamic library
From: Hyman Rosen on 18 Mar 2010 07:52
<http://connect.microsoft.com/VisualStudio/feedback/details/336316/missing-destructor-calls-when-optimization-is-enabled>

This was brought to my attention by someone with whom I
occasionally correspond about C++. (He can reply to identify
himself if he wishes.)

Two years after having an error in Visual C++ reported
whereby automatic objects of class type are not destructed
in certain cases, Microsoft has chosen to close the report
as "won't fix". I don't think anything has heralded the
death of C++ quite as much as this. The guarantee that
automatics are destructed on scope exit is so fundamental
to correct C++ that choosing not to fix such a problem is
a sign that the maintainers of the code do not understand
or care about the language any more. (As further proof,
the sample code which Microsoft posted to illustrate when
the problem occurs is itself incorrect, containing O obj();
as meaning a local object of type O when this is really a
declaration of a function named obj returning an O.)

{ Herb Sutter has already responded to this issue over in [comp.lang.c++], <url:
http://groups.google.com/group/comp.lang.c++/msg/a550e48ede18c2df>,

"We just looked at this again, and we agree and apologize. We're now planning
to ship a fix for this in the first service pack to VC++ 2010."

-mod }

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Edward Diener on 18 Mar 2010 18:11
On 3/18/2010 6:52 PM, Hyman Rosen wrote:
> <http://connect.microsoft.com/VisualStudio/feedback/details/336316/missing-destructor-calls-when-optimization-is-enabled>
>
>
> This was brought to my attention by someone with whom I
> occasionally correspond about C++. (He can reply to identify
> himself if he wishes.)
>
> Two years after having an error in Visual C++ reported
> whereby automatic objects of class type are not destructed
> in certain cases, Microsoft has chosen to close the report
> as "won't fix". I don't think anything has heralded the
> death of C++ quite as much as this. The guarantee that
> automatics are destructed on scope exit is so fundamental
> to correct C++ that choosing not to fix such a problem is
> a sign that the maintainers of the code do not understand
> or care about the language any more. (As further proof,
> the sample code which Microsoft posted to illustrate when
> the problem occurs is itself incorrect, containing O obj();
> as meaning a local object of type O when this is really a
> declaration of a function named obj returning an O.)
>
> { Herb Sutter has already responded to this issue over in
> [comp.lang.c++], <url:
> http://groups.google.com/group/comp.lang.c++/msg/a550e48ede18c2df>,
>
> "We just looked at this again, and we agree and apologize. We're now
> planning
> to ship a fix for this in the first service pack to VC++ 2010."
>
> -mod }

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

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.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Balog Pal on 19 Mar 2010 16:17
"Edward Diener" <eldiener(a)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(a)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! ]

From: Paul Bibbings on 19 Mar 2010 16:18
Hyman Rosen <hyrosen(a)mail.com> writes:

<snip />
> Two years after having an error in Visual C++ reported
> whereby automatic objects of class type are not destructed
> in certain cases, Microsoft has chosen to close the report
> as "won't fix". I don't think anything has heralded the
> death of C++ quite as much as this.
<snip />

I am completely failing to see how anyone can get from the statement in
your first sentence here to the opinion in the second. (Is this your
own thought, or are you quoting your correspondent here? I couldn't be
sure.) Under any other circumstances I would rather think that it would
herald the death of the implementation in question. The `Law' (to use a
stretched example) is not compromised by the people that break it.

Regards

Paul Bibbings

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Joshua Maurice on 19 Mar 2010 20:32
On Mar 20, 12:17 am, "Balog Pal" <p...(a)lib.hu> wrote:
> "Edward Diener" <eldie...(a)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/wa...
>
> > and
>
> >https://connect.microsoft.com/VisualStudio/feedback/details/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.
>
> 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...

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.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 |  Next  |  Last
Pages: 1 2
Prev: o.k. to use boolean expression as array index?
Next: linktime error for function overloads in template class when library is a dynamic library