# References in C++

## Recommended Posts

Hi Can anyone explain the following : int i = 10; int &refi = i; refi = i++; after the above statements, i still has the value 10. Can anyone tell the reason ... i gues i dont understands references properly :(

##### Share on other sites

[Edited by - DigitalDelusion on June 30, 2005 5:15:21 AM]

##### Share on other sites
LtJax    168
References basically act as aliases to the variables you initialize them with.
In this case, refi is then an alias for i. As you might know, the i++ operator increments i first (to 11) and then returns the value it had before the increment (which is 10) - so the i++ in this case evaluates to 10 and you got refi = 10 there after the increment has happenend. Now refi is only an alias for i and hence you just assign 10 to i again.
I hoped that helped.

##### Share on other sites
greldik    163
No, that's not possible. Unless your compiler has a bug in it (very unlikely)

The reference points to 'i' exactly as you would assume.
But that doesn't matter because you use the ++ operator. So 'i' will always be increased regardless of refi.

Okay, a couple of people beat me, and both states that the value 10 is correct. However, since he uses i++ the increment should not occur until _after_ the assignment to refi, thus i still should take the value of 11.
(which it does in vc8)
Or is this an undefined behaivour when using post-increment and assignment in the same statement?[/edit]

##### Share on other sites
valla2    100
wait, i thought i was a well known fact that what he is doing is undefined behaviour

##### Share on other sites
Shannon Barber    1681
Order of eval of pre & post inc is implementation dependant behavior.
That code also violates the '[no] variable aliasing' rule, and this is the primary cause of grief.

MSVC 7.1 shows a value of 11.

##### Share on other sites
valla2    100
i haven't heard of that "[no] variable aliasing' rule before. Does that mean that we shouldn't alias variables in the same scope. but there is no problem for different scopes?

##### Share on other sites
Quote:
 Original post by valla2wait, i thought i was a well known fact that what he is doing is undefined behaviour

Y is it undefined ?

What is "[no] variable aliasing ???

##### Share on other sites
valla2    100
the way i see it, and i could be wrong:
the statement
a = a++;
is undefined because
1) you don't know what will be evaluated first; the left part of operator = or the right part?
2) http://www.eskimo.com/~scs/C-faq/q3.2.html ( i think it's what Shannon Barber said )

##### Share on other sites
Guest Anonymous Poster
Quote:
 Original post by valla2the way i see it, and i could be wrong:the statement a = a++;is undefined because1) you don't know what will be evaluated first; the left part of operator = or the right part? 2) http://www.eskimo.com/~scs/C-faq/q3.2.html ( i think it's what Shannon Barber said )

there's no undefined behavior:

B = A++; > assign the value of A to B, and then increment A

B = ++A; > increment A, and assign its (incremented) value to B

So, if we go back to the original sample:

int i = 10;
int &refi = i;

refi = i++;

what happens here is that the compiler stores the value of 'i' in a temporary register, increments 'i' , then, assigns the temporary register to 'refi', and, since refi is also 'i', we get again 10.

still not clear?

##### Share on other sites
lucky_monkey    440
my 2¢: the most semantically consistent assignment method is for the compiler to generate code to fully evaluate the rhs then assign the result to the lhs. (i.e. this situation is expected and, really, the most logical choice for the compiler.)

##### Share on other sites
FlowingOoze    236
Quote:
 Original post by lucky_monkeymy 2¢: the most semantically consistent assignment method is for the compiler to generate code to fully evaluate the rhs then assign the result to the lhs. (i.e. this situation is expected and, really, the most logical choice for the compiler.)

The most logical choice for the compiler is the one that produces most efficient machine code.

##### Share on other sites
valla2    100
Quote:
Original post by Anonymous Poster
Quote:
 Original post by valla2the way i see it, and i could be wrong:the statement a = a++;is undefined because1) you don't know what will be evaluated first; the left part of operator = or the right part? 2) http://www.eskimo.com/~scs/C-faq/q3.2.html ( i think it's what Shannon Barber said )

there's no undefined behavior:

B = A++; > assign the value of A to B, and then increment A

B = ++A; > increment A, and assign its (incremented) value to B

That's completely different.
Nobody said about "B = A++;". We are talking about "B = B++". Read again my post...

Quote:
 So, if we go back to the original sample:int i = 10;int &refi = i;refi = i++;what happens here is that the compiler stores the value of 'i' in a temporary register, increments 'i' , then, assigns the temporary register to 'refi', and, since refi is also 'i', we get again 10.still not clear?

not clear yet :P. Look at your statement in bold ( i "bolded" it ). "i" is the same as "refi" so according to your (wrong) explanation what gets icremented at that stage is "refi" ( which will later lose this +1 value since it will get its previous value -according to you )

##### Share on other sites
Guest Anonymous Poster
AP is correct. There is no undefined behavior. this is exemplary of the very difference in the pre and post increment/decrment operators.

_gl_coder_one_ i suggest you try it with an i++ and then with an ++i to see the difference. also, reread APs explanation ... it is the answer you seek.

##### Share on other sites
from the standard:
Quote:
 Except where noted, the order of evaluation of operands of individual operators and subexpressions of individualexpressions, and the order in which side effects take place, is unspecified. Between the previous andnext sequence point a scalar object shall have its stored value modified at most once by the evaluation of anexpression. Furthermore, the prior value shall be accessed only to determine the value to be stored. Therequirements of this paragraph shall be met for each allowable ordering of the subexpressions of a fullexpression; otherwise the behavior is undefined. [Example:i = v[i++]; // the behavior is undefinedi = 7, i++, i++; // ‘i’ becomes 9i = ++i + 1; // the behavior is undefinedi = i + 1; // the value of ’i’ is incremented—end example]

the relevant example here is:
i = ++i + 1; // the behavior is undefined

##### Share on other sites
Guest Anonymous Poster
This kind of discussion has been on this forum before. Cant find the thread right now... But the answer/result was that there can only be one assignment to a variable per statement. Everything else is undefined/illegal. So your example is a no-no thing... Each compiler will probably generate different code, which Shannon Barber also confirmed.

##### Share on other sites
Guest Anonymous Poster
DigitalDelusion is correct all the way. Any other statement is plain "spam"... ;P

##### Share on other sites
Quote:
Original post by DigitalDelusion
from the standard:
Quote:
 Except where noted, the order of evaluation of operands of individual operators and subexpressions of individualexpressions, and the order in which side effects take place, is unspecified. Between the previous andnext sequence point a scalar object shall have its stored value modified at most once by the evaluation of anexpression. Furthermore, the prior value shall be accessed only to determine the value to be stored. Therequirements of this paragraph shall be met for each allowable ordering of the subexpressions of a fullexpression; otherwise the behavior is undefined. [Example:i = v[i++]; // the behavior is undefinedi = 7, i++, i++; // ‘i’ becomes 9i = ++i + 1; // the behavior is undefinedi = i + 1; // the value of ’i’ is incremented—end example]

the relevant example here is:
i = ++i + 1; // the behavior is undefined

Is this given in Stroustrup ?

##### Share on other sites
Quote:
 Original post by screwtapemy turn to try and explain why AP is correct

You're jumping to the same wrong conclusion that I first did.
The thing is that according to the standard the sequence point doesn't end until the whole expression is 'finnished' and side-effects (like increment) doesn't need to happen before that. The compiler is therefore free to interpret the statement i = i++ as either i = i, ++i or ++i, i = i and which you get is implementation defined.

##### Share on other sites
Guest Anonymous Poster
search for sequence points on MSDN

##### Share on other sites
Quote:
 Original post by _gl_coder_one_Is this given in Stroustrup ?

No it's a direct quote from the ISO C++ standard from 1998.

##### Share on other sites
MaulingMonkey    1730
Quote:
 Original post by DigitalDelusionThe compiler is therefore free to interpret the statement i = i++ as either i = i, ++i or ++i, i = i and which you get is implementation defined.

I should note that the two implementations you've listed will be equivilant, as "i = i" does nothing (as i allready equals i), leaving only ++i in both statements.

AFAIK what you're meaning to say is this:
old_i = i
Then:
i = old_i, ++i;
Or:
++i, i = old_i;
Just clarifying.

##### Share on other sites
Quote:
Original post by MaulingMonkey
Quote:
 Original post by DigitalDelusionThe compiler is therefore free to interpret the statement i = i++ as either i = i, ++i or ++i, i = i and which you get is implementation defined.

I should note that the two implementations you've listed will be equivilant, as "i = i" does nothing (as i allready equals i), leaving only ++i in both statements.

AFAIK what you're meaning to say is this:
old_i = i
Then:
i = old_i, ++i;
Or:
++i, i = old_i;
Just clarifying.

Yes, I was thinking about the order of operations dunno why I swizzled the ++:es around.