-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2001-04-28 at 14:12 Raymond Wiker wrote:
> Anyway, I came across the following bug report:
><URL:http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00707.html>. This
>looks pretty serious.
Sorry, but this is not a bug. The expression:
cout << f(d) << "\t" << d << endl;
is equivalent to:
(((cout << f(d)) << "\t") << d) << endl;
which is equivalent to:
(((cout.operator<<(f(d))).operator<<("\t")).operator<<(d)).operator<<(
endl);
And then you come to the nice part of the story: operator '.' is NOT
required to evaluate its operands in any particular order! What most
compilers do with this type of code is produce something like the
following (in pseudo-assembly):
// push arguments back-to-front:
push endl;
push d; // (*) here the value is still 5
push "\t";
push d; // still 5
call f; // here d's value is modified to 1
// call operator<<'s, popping stack as you go
call operator<<(double); // for f(d)
call operator<<(const char*); // for "\t"
call operator<<(double); // for d, which is 5, see (*)
call operator<<(endl); // for endl
And this will lead to the results from the bug report. It not only
happens with g++, but also with VC++ under Win32, for example.
The problem is that you should not put code with side effects (such
as calling f() in this case) in cout << ... expressions. This will
lead only to unexpected results. :)
Cheers,
- --
Dimitry Andric <[EMAIL PROTECTED]>
PGP key: http://www.xs4all.nl/~dim/dim.asc
KeyID: 4096/1024-0x2E2096A3
Fingerprint: 7AB4 62D2 CE35 FC6D 4239 4FCD B05E A30A 2E20 96A3
-----BEGIN PGP SIGNATURE-----
Version: Encrypted with PGP Plugin for Calypso
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm
iQA/AwUBOurBPrBeowouIJajEQJ2TACg1+b4J3OjTEFqpBT747nEcZhr1aUAoJCC
ZRXzJYLt1Ig9MFY4yLNfiNF+
=HO0F
-----END PGP SIGNATURE-----
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
