Go4Expert (http://www.go4expert.com/)
-   C++ (http://www.go4expert.com/forums/cpp/)
-   -   Evaluation order for << (http://www.go4expert.com/forums/evaluation-order-for-t3792/)

esrrms 8Apr2007 02:31

Evaluation order for <<
Lets say I have a function called html() that returns a string of "<html>". It also saves it state so that the first time it returns "<html>", but the second time it returns "</html>", then on the third it goes back to "<html>";

If I have this code...


I get this output...

But if I have this code...

I get...

Any way to get the second code to output like the first code?

DaWei 8Apr2007 05:50

Re: Evaluation order for <<
Would it be too much trouble to actually post the code for html ()?

esrrms 8Apr2007 15:08

Re: Evaluation order for <<

bool b_html;

std::string html()
std::string s;

s = "</html>";
b_html = false;
s = "<html>";
b_html = true;

DaWei 8Apr2007 17:54

Re: Evaluation order for <<
Scratch this post, bad information.
Consider these statements:

int i = 0;
cout << i++;
cout << i++;
cout << i++ << i++;

This code may produce either 1234 or 1243, depending on the implementation. It is undefined as part of the C++ language. It won't produce 0... anything, because the post-increment operator has higher precedence than the << operator.

In this code, the only sequence points are represented by the semicolons. A sequence point guarantees that all expressions have been evaluated at that point. The ORDER of evaluation of certain things is defined; the order of evaluation of other things is left up to the implementors of the system. This is based on the fact that the need to do things efficiently may require one method on one implementation and another method on another implementation.

In the case shown, the << operator has the lowest precedence. It will be evaluated last. Since there are two of them, they WILL be evaluated left-to-right, as you expect.

The fly in the ointment is that the order of evaluation of the expressions in between the << operators is implementation dependent. It can go either way, just as the order of evaluations of function arguments can. The problem arises when the expressions have side effects. In the last statement, which i++ is evaluated first? Obviously, in your implementation, the second one is evaluated first, then the first one is evaluated, then the first one is output (with the side effects of evaluating the second one in place), then the second one is output.

Even though the expressions between the << operators may be evaluated in any order, operators WITHIN those expressessions might impose precedence. 2 + 3 * 4, for example, will be evaluated differently than (2 + 3) * 4, but that doesn't impose any necessary order for the encompassing expressions. One has to determine in individual cases if an order is imposed by the language, or if it is undefined and left to the implementation. One then copes. Don't chain them together, in this case. Introduce a sequence point.

All times are GMT +5.5. The time now is 14:24.