Dimitry Andric writes:
> > 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. :)
Damn :-) I was hoping I had found the reason that my code had
stopped working, but that does not appear to be the case. Oh well,
I guess I'll have to get back to debugging again, then.
Thanks to you, and to Erik Trulsson, for putting me straight
on this.
//Raymond.
--
Raymond Wiker
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
