+ 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?

5th Mar 2022, 10:41 AM
Sebi Poiana
Sebi Poiana - avatar
36 ответов
+ 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).
5th Mar 2022, 11:29 AM
Ipang
+ 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
5th Mar 2022, 12:50 PM
A͢J
A͢J - avatar
+ 4
Yes, both <a> and <b> will have value 9.
5th Mar 2022, 11:32 AM
Ipang
+ 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.
5th Mar 2022, 12:03 PM
Ipang
+ 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.
5th Mar 2022, 9:05 PM
Ipang
+ 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.
6th Mar 2022, 4:35 AM
Ipang
+ 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.
6th Mar 2022, 2:27 PM
Brian
Brian - avatar
+ 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>
5th Mar 2022, 11:42 AM
Ipang
+ 2
ℂ𝕙𝕚𝕘𝕠𝕫𝕚𝕖 𝔸𝕟𝕪𝕒𝕖𝕛𝕚🇳🇬 please correct your answer. Both a and b are incremented.
5th Mar 2022, 3:29 PM
Brian
Brian - avatar
+ 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 👍
5th Mar 2022, 3:55 PM
Ipang
+ 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
5th Mar 2022, 4:11 PM
Ipang
+ 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.
5th Mar 2022, 9:58 PM
Brian
Brian - avatar
+ 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.
6th Mar 2022, 9:48 AM
Hiba al-Sayf
Hiba al-Sayf - avatar
+ 2
You are incrementing a before assigning a value to b...and hence the behavior.
6th Mar 2022, 11:00 AM
Sanjay Kamath
Sanjay Kamath - avatar
+ 2
It is called pre-increament operator, it increment the value first , that's why here a & b both will be increased by 1.,.
6th Mar 2022, 1:46 PM
Neeraj Kumar
Neeraj Kumar - avatar
+ 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++
6th Mar 2022, 3:40 PM
Brian
Brian - avatar
+ 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.
6th Mar 2022, 9:00 PM
Brian
Brian - avatar
+ 2
Brian Thanks a lot
7th Mar 2022, 1:42 AM
Je Foip Cent
Je Foip Cent - avatar
+ 1
I have this co fusion: a = 8 b = ++a; Wouldn't both become 9?
5th Mar 2022, 11:30 AM
Sebi Poiana
Sebi Poiana - avatar
+ 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?
5th Mar 2022, 11:33 AM
Sebi Poiana
Sebi Poiana - avatar