-
When I compile code it doesn't print value as expected
#include<stdio.h>
#include<stdlib.h>
int main()
{
int x = 1;
int y = x++;
printf("x : %d\n", x);
printf("y : %d\n", y);
return 0;
}
x : 2
y : 1
I was expecting 1 should print for variable x. when I researched about it, I found that I need to understand difference between pre and post increment oprator. I tried to figure it out but it's going off the top of my head
-
I was expecting 1 should print for variable x. when I researched about it, I found that I need to understand difference between pre and post increment oprator. I tried to figure it out but it's going off the top of my head
You should expect 2 for x.
If you write "x++" it means "x = x + 1". "x++" changes the value of x.
This is not about the difference between pre- and post- increment. The important part here is "increment", i.e. "add 1 to". If x is 1 and you increment it, it becomes 2.
In other words, what your code does is this:
int x = 1;
int y = x; x = x + 1; // same as y = x++;
-
When I compile code it doesn't print value as expected
#include<stdio.h>
#include<stdlib.h>
int main()
{
int x = 1;
int y = x++;
printf("x : %d\n", x);
printf("y : %d\n", y);
return 0;
}
x : 2
y : 1
I was expecting 1 should print for variable x. when I researched about it, I found that I need to understand difference between pre and post increment oprator. I tried to figure it out but it's going off the top of my head
The output is correct.
You incremented x before you printed it.
-
what does this produce :
y = (x++);
i never liked code like this.
To me, both x and y should be identical
i read this as 'set y to the result of x++' unwrapped further : increment x. assign result to y"
x = x + 1;
y = x;
constructions like this make it difficult for non-coders to understand what exactly is going on. You need to know too many little details.
-
To me, both x and y should be identical
I'm glad you haven't designed the C language.
Pre- and post-incrementation operands are some of the easiest to learn.
In more complex examples, concept of sequence points needs to be learnt. In your simple example - irrelevant. Adding extra parenthesis - irrelevant, as it should be. Your idea that parenthesis should change the meaning, is just pure horror.
x++ increments x, and returns the old value of x. It's totally beyond me why adding extra parenthesis should change the meaning of x++.
-
So this forum is turning into a free course? One question is fine, but a series of them in a row that are all very basic, I call that a free course.
-
That's fine, that's why forums exist.
Nobody is forcing you to answer!
Or maybe yes? Is someone pointing you with a gun? :-DD
-
I find that an abusive use of a forum. A forum's purpose is not to mitigate people's laziness to even open a book. But I'll let Dave be judge of that - it's his forum, not mine. Even if he doesn't care about that, the questions here don't have anything to do with microcontrollers specifically, so it's just polluting the section. Just my 2 cents.
As to the question, just opening a book on C would answer this in a jiffy. As I and a few others note on a regular basis, it's amazing how so many people insist on using C without caring to learn it, and just want to figure it out as they go. And universities which increasingly do not teach it either, yet ask students to use it. It's mind-boggling, and an overall concerning issue, but hey. Let's drown together, it's more fun. =)
-
I find that an abusive use of a forum. A forum's purpose is not to mitigate people's laziness to even open a book. But I'll let Dave be judge of that - it's his forum, not mine. Even if he doesn't care about that, the questions here don't have anything to do with microcontrollers specifically, so it's just polluting the section. Just my 2 cents.
Perhaps use the "report to moderator" link that is in the bottom right of every post, if you feel it should go into some other section (theres a dedicated programming section for example)?
But I'd agree that this is not microcontroller specific (none of the other questions the OP has posted in this forum seem to be either), so it should probably be moved to the programming forum.
-
Sincerely, I find a lot more abusive those threads asking some very specific and direct subject, ending in 8 pages of no sense offtopic :popcorn:
-
When I compile code it doesn't print value as expected
#include<stdio.h>
#include<stdlib.h>
int main()
{
int x = 1;
int y = x++;
printf("x : %d\n", x);
printf("y : %d\n", y);
return 0;
}
x : 2
y : 1
I was expecting 1 should print for variable x. when I researched about it, I found that I need to understand difference between pre and post increment oprator. I tried to figure it out but it's going off the top of my head
Pre-increment won't make any difference to the final value of x. You're incrementing it either way.
Pre-increment of x will make *y* have a different value -- the same as the new value of x instead of the old value.
-
I find that an abusive use of a forum. A forum's purpose is not to mitigate people's laziness to even open a book. But I'll let Dave be judge of that - it's his forum, not mine. Even if he doesn't care about that, the questions here don't have anything to do with microcontrollers specifically, so it's just polluting the section. Just my 2 cents.
As to the question, just opening a book on C would answer this in a jiffy. As I and a few others note on a regular basis, it's amazing how so many people insist on using C without caring to learn it, and just want to figure it out as they go. And universities which increasingly do not teach it either, yet ask students to use it. It's mind-boggling, and an overall concerning issue, but hey. Let's drown together, it's more fun. =)
I agree with you in all this.
We've been having problems recently on the RISC-V "sw-dev" mailing list with a guy (from the same country, probably not coincidentally) who is trying to port some C package to RISC-V and is having problem after problem, none of which require even the slightest knowledge of RISC-V to solve.
He's asked *twice* now about different code sections that say something like ...
#IFDEF USEMEMCPY
memcpy(x,y,sz);
#ELSE
... some code that uses SSE instructions
#ENDIF
... and it blows up the RISC-V compiler when it hits the SSE instructions.
Not exactly hard to solve.
Looking at the code, they'd probably be better off just using memcpy() on x86 too, not least because SSE isn't the latest and greatest thing now like it might have been when the code was written.
-
Well, seeing how this is going, I must agree with SiliconWizard
That's very basic stuff, so much that he should be reading C books for begginers or watching YouTube tutorials.
Well...
All examples start with y=6
x = y+1 x=7, y=6
x = y++ x=6, y=7
x = y++ +1 x=7, y=7
x = ++y x=7, y=7
x = ++y +1 x=8, y=7
x = ++y++ x=7, y=8
x = ++y++ +1 x=8, y=8 Nope OMG.
-
So this forum is turning into a free course? One question is fine, but a series of them in a row that are all very basic, I call that a free course.
I am reading books. I asked specific questions which I did not understand while reading the topic. I understand your point that this is microcontroller forum and i should ask microcontroller related question. actually i want to earn c programming for microcotroller but i am not that good in c programming so i am practicing c programming on my PC. Once I understand the basic concept of C programming I will start writing programs for microcontrollers.
-
So this forum is turning into a free course? One question is fine, but a series of them in a row that are all very basic, I call that a free course.
I am reading books. I asked specific questions which I did not understand while reading the topic. I understand your point that this is microcontroller forum and i should ask microcontroller related question. actually i want to earn c programming for microcotroller but i am not that good in c programming so i am practicing c programming on my PC. Once I understand the basic concept of C programming I will start writing programs for microcontrollers.
If your questions are generic programming related questions, you'd be better off posting them in this forum: https://www.eevblog.com/forum/programming/ (https://www.eevblog.com/forum/programming/)
-
x = ++y++ x=7, y=8
x = ++y++ +1 x=8, y=8
No.
You are modifying an object twice between sequence points which is definite no-no.
From "J.2 Undefined behavior" in C11:
— A side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object (6.5).
This is the "new" formulation, C99 used sequence points but the meaning is exactly the same.
The gist of the problem is that it is not defined in which order the side effects (increments) happen with respect to the act of providing a value for the sub-expression.
Another compiler, or the same a different day, might behave in a completely different way.
The behaviour being undefined, nasal demons are also an option.
This does not even compile, see my post below.
The consideration above are still valid for stuff like x = y++ + ++y;
-
You're right :palm:
I had never tried that, thought it was possible, didn't seem to cause any undefined behavior:
"x = ++y++" would translate as :
Increment y, copy y to x, increment y.
Edited the screw up and I hope nobody sees it again ever ::)
-
Actually, now that I think of it, this is a syntax violation so it should really not even compile!
Postfix increment or decrement binds stronger than prefix, and the result of the sub expression is definitely not an lvalue.
All self respecting compilers should give an error.
-
Nope, of course it doesn't compile :phew:
-
Actually, now that I think of it, this is a syntax violation so it should really not even compile!
Postfix increment or decrement binds stronger than prefix, and the result of the sub expression is definitely not an lvalue.
All self respecting compilers should give an error.
If the human reading the code has to spend all of this brain power trying to understand how the compiler handles it, or what the language standard says about it, then ... maybe the human writing the code should not be so clever.