Sign in to follow this  
_gl_coder_one_

References in C++

Recommended Posts

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 this post


Link to post
Share on other sites
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.

[edit]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 this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by valla2
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 )


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 this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
Quote:
Original post by lucky_monkey
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.)

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

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by valla2
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 )


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 this post


Link to post
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 this post


Link to post
Share on other sites
from the standard:
Quote:

Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual
expressions, and the order in which side effects take place, is unspecified. Between the previous and
next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an
expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The
requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined. [Example:
i = v[i++]; // the behavior is undefined
i = 7, i++, i++; // ‘i’ becomes 9
i = ++i + 1; // the behavior is undefined
i = i + 1; // the value of ’i’ is incremented
—end example]


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

Share this post


Link to post
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 this post


Link to post
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 individual
expressions, and the order in which side effects take place, is unspecified. Between the previous and
next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an
expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The
requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined. [Example:
i = v[i++]; // the behavior is undefined
i = 7, i++, i++; // ‘i’ becomes 9
i = ++i + 1; // the behavior is undefined
i = 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 this post


Link to post
Share on other sites
Quote:
Original post by screwtape
my 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 this post


Link to post
Share on other sites
Quote:
Original post by DigitalDelusion
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
Quote:
Original post by DigitalDelusion
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.


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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this