Re: vc 6.0's bug?????
First, re moderation policy:
===================================== MODERATOR'S COMMENT:
I'm approving this for an odd reason. This question isn't quite
on-topic because it doesn't directly deal with the C++ standard,
but many of the possible answers to the question do directly
deal with the C++ standard. Let's make sure to keep followups
focused appropriately.
------=_Part_4136_31897272.1146154564994
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
approve<br>comment<br>I'm approving this for an odd reason. This question i=
sn't quite <br>on-topic because it doesn't directly deal with the C++ stand=
ard,<br>but many of the possible answers to the question do directly <br>
deal with the C++ standard. Let's make sure to keep followups <br>focused a=
ppropriately.<br>
------=_Part_4136_31897272.1146154564994--
===================================== END OF MODERATOR'S COMMENT
I suggest that the group's FAQ and/or moderation guidelines should
include, in addition to the FAQ's current reference to RFC 1855:
* preferentially don't post with quoted printable encoding (QP is for
e-mail, not news),
* preferentially don't post HTML, and
* preferentially don't post multi-part messages.
But as evidently happened here, such settings can be applied by mistake,
or via too "helpful" software. Is it perhaps possible to automatically
detect & reject "Content-Type: text/html" and
"Content-Transfer-Encoding: quoted-printable"?
* fisker0303@126.com:
In vc 6.0:
#include <iostream>
using namespace std;
int main()
{
int a = 10;
int b = 20;
a = (a + b) - (b = a);
cout << "a=" << a << ",b=" << b << endl;
return 0;
}
Release output : a ,b=10
Debug output: a=10,b=10
why?
Why you get that output: C++ does not generally guarantee the evaluation
order of an expression (the built-in boolean operators are exceptions),
and so (as I see it) the expression has unspecified effect: either 'b=a'
is evaluated before 'a+b', or after, at the compiler's discretion.
If it were 'a' being modified, the behavior would not (IMO) be merely
unspecified, but undefined, which is much worse. But the examples in
the standard, para ?5/4, say "unspecified" where the normative text says
"undefined", so there was evidently some confusion back in 1998. That
has already been fixed; Tom Widmer once directed me to <url:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#351>.
I think the intention had to be that also in the case above the effect
should be undefined, so I think that ?5/4 should either be fixed to
include the case above as undefined behavior, or be changed to yield
well defined, deterministic behavior.
Why it is like that: once, very long ago, say, around 1972, computers
were really slow. So /a constant factor/ of improved efficiency
mattered a lot; even a marginal improvement could be crucial. And the
computers were also rather primitive, so much so that the compiler's
detailed machine code optimization of expressions directly influenced
efficiency at this level (the hardware didn't do predictive and parallel
execution and such things). So, the more freedom the compiler had to
reorder things in a then "optimal" way, the better for efficiency.
So in C++, for historical reasons, we pay the price, again and again,
but except possibly in embedded systems don't ever get the goods --
they no longer exist, in practice.
Today it seems the 80 to 90% consensus is that deterministic evaluation,
that you can always predict at the "as-if" level which operations will
be executed in which order, matters much much more than whatever
now-really-marginal-if-any improvement of efficiency can be had via free
reordering of expressions. At a slightly more abstract level, namely
reordering of statement execution order under "as-if" rules, as I
understand it it's also desirable for multi-threaded programming. E.g.,
Sutter and Alexandrescu (I think it was) once wrote an article about why
the double-locking pattern isn't supported by current C++.
The problems, as I see them, are that (1) changing the standard in this
respect would probably break a lot of existing code, and (2) it might
-- I don't know -- be problematic for embedded systems programming.
One solution to problem (1) is to say, so what, let's break that code
(after all, it's probably maintained using some old compiler that won't
be upgraded precisely to keep the code working); that was done in 1998.
Another solution to (1) is to e.g. define a macro symbol that specifies
the old unpredictable behavior, say, __UNPREDICTABLE__ (or, after the
marketing department has had its say, __ULTRA_EFFICIENT__), so that for
new compilers, deterministic behavior is by default. This solution has
the advantage of keeping C++ as a practical efficient-enough language
for embedded systems programming, if that actually is a problem. I.e.,
it also solves the hypothetical problem (2).
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]