|
#include <stdio.h>
int main(void)
{
int x=2;
printf("%d\n%d\n",x++,x++);
}
why the result is 4 4 not 3 4 ?!
|
|
|
|
|
Google for "order of evaluations." It's a much-talked-about subject.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
The order of evaluation of the two post increment operations (x++) is not guaranteed. Using gcc I get 3, 2, using clang I get 2, 3. Both are valid answers, as are would be any combination of 2, 3 and 4. In fact, it would not be a surprise if different levels of optimization produced different results.
I think the only thing that can be guaranteed is that the value of x will be 4 after the call to printf().
|
|
|
|
|
You got this result because the optimizations are on.
The compiler choose an optimization that leads to the final result not considering what the values could be in the same call. This is consistent with C99, C11 and C++11 standards that to privilege the best optimization of code state that the order of evaluation of the parameters of a function is undefined, and compiler dependent (but also situation dependent different conditions of optimization will lead to different results).
If you test your code with different compilers you'll get different results.
Please consider that even with optimizations off the compiler could give 'strange' values.
BTW the more common output you should expect should be '4 3', because the parameters should normally be evaluated from right to left (incrementing 2 to 3 and pushing it on the stack, then incrementing it to 4 and pushing it on the stack).
When optimization are on basically the compiler decides to make a double increment in one time (instead of move back to the same variable for a second increment).
|
|
|
|
|
The code produces undefined behavior - you are modifying an 'lvalue' twice between 'sequence points'.
Undefined behavior means precisely that; the compiler is at liberty to generate code that will format your disk, or even make demons fly out of your nose.  Be thankful that all it did was give you an unexpected result.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Hmm, I never had demons fly out of my nose - I think I need to try harder! 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
One of the regulars on the newsgroup comp.lang.c invented a notional system - the DeathStation 9000. The C compiler for that system would interpret undefined and implementation-defined behavior in the worst possible manner, up to and including creation of nasal demons...
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Well after finishing logical gates and making the Computer.hdl
(Nand2tetris)
We started learning about assembly
this is only the second lesson and we learnt so far a bit about offset lea and signed and unsigned
i need help solving this exercise and on the way the explenation why and how because iv been searching tyhe web for 2 days now and i got no luck so far
; Print '15', using ONLY 'mov' and 'lea'.
; Do NOT use arithmetic instrutions (add, inc, mul, etc.)
PRINTN "Part (C) - should print 15"
mov ax,10
mov bx,4
mov cx, lea [ax + bx+1]
mov ax,cx
call print_num
PRINTN
modified 4-Jun-15 14:07pm.
|
|
|
|
|
a random user wrote:
i need help solving this exercise...
Just curious, but isn't that what the instructor (or the TA) is for? Are instructors these days just off limits to questions?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
the instructers are not allowed to help us
|
|
|
|
|
But a bunch of strangers are?
|
|
|
|
|
Who are you calling strange, Richard? 
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
|
As a rule, we don't help with homework. That said, I'll give you a hint; the solution is related to loading ASCII codes for characters into AX.
|
|
|
|
|
|
How to give administrator rights to my mfc application without manifest file
|
|
|
|
|
You can specify to "run as administrator" in the shortcut that points to the program.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thanks for your valuable information but i would like to ask admin rights to my application programatically while run by the user.
|
|
|
|
|
You cannot set administration rights within a program, it must be set externally by the manifest, or by the user at startup. There would be no point in having a security framework if it was possible.
|
|
|
|
|
Inorder to prevent the theme from modifying my application i have disabled the manifest file the admin rights is found in the manifest file.what should i do to prevent my application being modified by theme without disabling manifest.Your suggestion would help me a lot.
|
|
|
|
|
|
I've got a relatively large project (400K lines) that was developed in Embedded Visual C++. For all intensive purposes, you can consider EVC++ pretty close to VS6. We're migrating to a new OS that requires the use of at least VS2008. Needless to say, the much older compiler allowed us to commit a multitude of sins that the new compiler tosses it's cookies on.
I'm pretty sure I could pragma myself to death, but that's "cheating". I'd like to lift the code to a more modern state. Does anyone know of any tools or approaches that can be applied to a set of code that would do most of the heavy lifting? For example, the older compiler allowed methods with no return type. Most of these will be void returns, but at something like 8K errors, it's going to be a lot of $hit shoveling.
Appreciate any ideas.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Set the compiler to report Level 4 warnings.
Compile, Fix the issues manually, Compile, the issues manually, ... ,
Make certain it works.
After, if you have time (and money, as time==money), then you can start to "lift" the code to a more modern state.
Other than that, good luck.
I'd rather be phishing!
|
|
|
|
|
 yeah, that's what we're looking at... reaching for shovel.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
been there, done that.
The hard part is actually not doing refactoring while doing the updgrade and cleaning compilation warnings
I'd rather be phishing!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
