weird behavior of algbraic evaluation in concatenated operators

D

dejan budimir

hi there!

#include <iostream>
using namespace std;

void main(){

int i=0,
j=10;

//Case one (the 'common' case):
cout<< "i == " << i << endl
<< "j == " << j << endl;

//Case two (the 'oddity'):
//Should print 1 and 11 (but will not evaluate the former expression
// before the latter, although it is printing in the correct order.
cout<< "(i+=1) == " <<(i+=1)<< endl
<< "(j+=i) == " <<(j+=i)<< endl;
}

The ostream's operator<<() method is defined as to be passed only two
arguments a time, one of which must be the class, which is being
returned to allow concatenation.

(cout<<expr1)<<expr2;

But it seems as if the whole set of expressions is being evaluated,
_before_ becoming the arguments of the operator methods and, in
addition, is being evaluated from the right to the left (from the
stack?).

Is this a microsoft-specific way of dealing with concatenation?

Havv ei got zee opchions wronk?
 
R

Rolf Magnus

dejan said:
hi there!

#include <iostream>
using namespace std;

void main(){

main() must return int.
int i=0,
j=10;

//Case one (the 'common' case):
cout<< "i == " << i << endl
<< "j == " << j << endl;

//Case two (the 'oddity'):
//Should print 1 and 11 (but will not evaluate the former expression
// before the latter, although it is printing in the correct order.
cout<< "(i+=1) == " <<(i+=1)<< endl
<< "(j+=i) == " <<(j+=i)<< endl;

This invokes undefined behaviour because both i and j are modified twice
without a sequence point in between. In theory, anything can happen.
}

The ostream's operator<<() method is defined as to be passed only two
arguments a time, one of which must be the class, which is being
returned to allow concatenation.

(cout<<expr1)<<expr2;

But it seems as if the whole set of expressions is being evaluated,
_before_ becoming the arguments of the operator methods and, in
addition, is being evaluated from the right to the left (from the
stack?).

Probably, but the C++ standard doesn't state any order of evaluation.
 
D

dejan budimir

thanks! that really was fast.
would be great to know what it actually is that "goes wrong", though.
but, since i'll have to learn assembly anyway, i guess it's just a
matter of banana.

have a nice one!
 
K

Karl Heinz Buchegger

dejan said:
thanks! that really was fast.
would be great to know what it actually is that "goes wrong", though.

What "goes wrong": The way you wrote your program.
The C++ language simply does not define what should happen in this case.
 
D

dejan budimir

Karl said:
What "goes wrong": The way you wrote your program.
The C++ language simply does not define what should happen in this case.
yes, thank you.
 
O

Old Wolf

Rolf Magnus said:
This invokes undefined behaviour because both i and j are modified twice
without a sequence point in between. In theory, anything can happen.

i and j are both only modified once, in this statement.
The UB is because i is read for a purpose other than to determine
its new value.
 
R

Rolf Magnus

Old said:
i and j are both only modified once, in this statement.

Oops. You're right of course.
The UB is because i is read for a purpose other than to determine
its new value.

And that's right, too. Sorry for the confusion.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top