+ 2
Only b or just a? Incrementing with ++?
I don't understand something. When we write a = 8 and b= ++a, does a get incremented as well or just b?
38 Respostas
+ 8
int a = 8, b = ++a;
printf( "%d %d\n", a, b ); // 9 9
Here <a> is incremented first before its value is assigned to <b>
int a = 8, b = a++;
printf( "%d %d\n", a, b ); // 9 8
Here <a> is planned to be incremented (not yet), and <b> gets the original value of <a> (value of <a> before <a> was incremented).
+ 7
Sebi Poiana
post increment - first assign then increment
pre increment - first increment then assign
So
a = 8
b = ++a; //here first increment then assign
so a = 9, b = 9
a = 8
b = a++; //here first assign then increment
So b = 8, a = 9
+ 4
Yes, both <a> and <b> will have value 9.
+ 4
[1] int a = 8;
[2] int b = ++a;
<a> is incremented by pre-increment operator on line [2], its value changes to 9. And <b> also gets the incremented value of <a>.
[1] int a = 8;
[2] int b = a++;
<a> is not yet incremented at line [2], the post-increment operator will take effect on the successive lines - past line [2]. This way <b> gets the value of <a> which was not yet incremented.
+ 4
Brian,
I see you have edited your last response.
The last expression you have shown ...
b = x++ - x;
Is a common cause for unpredictable output due to the mixing of access and modification of data (x) in that line.
Other languages like Java or C# have an agreement on how such things are to be evaluated. That is because a common compiler is used.
This is not the case with C/C++, where various compilers available, whilst the C++ standards is not dictating how compilers should evaluate such expressions.
I'm sure you have seen, how people got confused trying to figure out why these types of "riddle" yields different, unexpected and/or unpredicted output in C/C++.
a++ - ++a + a + b-- + ++b - b;
General rule when it comes to C/C++, *NEVER* mix data access and modification in an expression to be evaluated. Result is unpredictable and *may* vary by compiler.
A decent compiler usually warns us when it sees a code possibly have undefined result.
+ 3
Brian,
Did I write that? I wrote that data modification by post increment/decrement operator will take effect after the line was completely evaluated.
int b = a++;
The post increment operation takes effect after the line was completely evaluated, when semicolon is reached, not at the event of value assignment to <b>.
I tried to scroll back up to see whether I wrote "post increment occurs after the assignment..." but I couldn't find any of my reply stating that. Point me to it in case I skpped it, so I can edit it to a better wording.
+ 3
Ipang good enough, thank you. BTW, your English is excellent! I feel that we have sharpened the point to the extent that the topic has become painful to other readers. :-)
Unless there are other questions, I will happily move on.
+ 2
Yes, but <a> will be incremented after the execution point (here the line) has been completely processed.
int a = 8;
int b = a++; // <a> is still 8, <b> gets 8
printf( "%d %d\n", a, b ); // here <a> has been incremented
// <b> has previous value of <a>
+ 2
āšššš š«šš šøššŖššššš³š¬ please correct your answer. Both a and b are incremented.
+ 2
Brian,
What did you mean no rule? are you saying these operators have no clear definition of what they do, or when they do it?
Self assignment combined with post increment/decrement can be messy. Although that wasn't what the OP asked for, it makes a good tips š
+ 2
Brian,
The post increment/decrement operator has higher precedence over the pre increment/decrement operator, which has higher precedence over the assignment operator.
Thus the post or pre increment/decrement operation always gets higher execution priority, assignment operation follows after.
https://en.cppreference.com/w/cpp/language/operator_precedence
+ 2
Ipang The edit was to clarify my wording and remove 1 as an alternate outcome, which is not possible.
I tested x = x++ on Sololearn in C, C++, C# and Java. In all tests it was consistent with the C++ precedence rule you pointed out. They behaved like:
temp = x
x = x + 1 // update x before assign
x = temp // overwrite x+1
This brings me back to the reason I joined the thread here. I was raising doubt in the statements that both you and AĶ¢J gave. You wrote that post increment occurs after the assignment statement executes. Instead it bears out that it occurs during the statement, and before the assignment.
My past experience with various C-based compilers on post-increment has been that they have been inconsistent, so I tiptoe around these subtleties. I think it depended on whether the processor natively supported autoinc/decrement addressing modes.
+ 2
b = ++a;
is shorthand for
++a;
b = a;
So a gets incremented to 9, and b gets assigned that incremented value.
Technically, b is not incremented but assigned the value of a after a is incremented.
+ 2
You are incrementing a before assigning a value to b...and hence the behavior.
+ 2
It is called pre-increament operator, it increment the value first , that's why here a & b both will be increased by 1.,.
+ 2
HungryTradie I align with all your remarks except the one about the for loop:
"for (i=0Ā Ā Ā ;i<9Ā Ā Ā ;++i) //this can be trusted to always increment i by +1 before running the loop."
Incorrect. The third expression field always executes at the end of the loop, never before it starts. Only the first field executes before it starts. The second executes at the beginning of the loop. The third executes at the end.
for (i=0Ā Ā Ā ;i<9Ā Ā Ā ;++i) //same as i++
+ 2
Liam B. Harrison I have examined that question, and I don't think we can say generally which type of increment is faster. The investigations that I have done and seen show there is no difference in clock cycles. Though I can point out there is hypothetical potential for a difference in some CPU/compiler combinations, where the CPU natively supports ++x and x-- but not x++ and --x. Hypothetically the compiler might use an extra instruction to accomplish the latter two types.
If it truly matters in your specific application then you should do benchmarks and/or examine the assembly code. Otherwise, choose according to style, readability, and necessary logic.
+ 2
Brian Thanks a lot
+ 1
I have this co fusion:
a = 8
b = ++a;
Wouldn't both become 9?
+ 1
Ok, and if it were a++, then a would be equal to 9 because it got incremented and b will be equal to 8 because it provides it the initial value of a?