In effect, yes. Alternatively:
Code:*(s->top) = c; (s->top)++;
In effect, yes. Alternatively:
Code:*(s->top) = c; (s->top)++;
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Ixnay. The post-increment will occur before the assignment. If the point is to add one to the value of s->top, the ++ does nothing in the end.
If the point is to make s->top point to what was the equivalent of s->top[1], then that space better be part of s, because it will be set to the value of c.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Sorry -- I was looking at this order of precedence table:
C Operator Precedence Table
However, it's obviously wrong as even the simple:
demonstrates (which if it were my code, I'd have been writing it and noticed )Code:int a = 5, b = a++;
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Precedence controls order of binding, not order of operations. It specifies which operations will occur to which expressions, not when they will occur. The order of operations is controlled by associativity and sequence points. Operators in different precedence classes are treated independently when determining associativity.
On top of all that, the compiler can evaluate the expression any way it likes, so long as the result is the same as if it had done it in the order defined by the language.
The code in question looks like it's pushing something onto a stack.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Well that is very deceptive then isn't it
I guess the best means of resolving uncertainty is still actual experimentation.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
In most cases, binding order completely defines order of operations. It's just that it doesn't cover every case. Even expressions that don't involve increment/decrement operators can have ambiguous evaluation order:
You can't tell whether a * b will evaluate before, or after, c * d. Left-to-right associativity doesn't factor in, because of the intervening addition. Even parenthesizing the expression doesn't remove the ambiguity. The only way to force a particular order is to insert a sequence point by splitting across more than one statement.Code:x = a * b + c * d;
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}