Captain Obvious
-
Isn't the question just whether the runtime environment first assigns the old value. I really thought this would just eventually increment the variable. Because it should normally first assign the old value to i, and then increment i. Why should it ever store the old value somewhere first, then increment i, then put that old value back in i? I know I'm wrong, cuz as said before C# gives an infinite loop, but still it's weird.
How could it do that? The operator's function has to end (return) before the assignment occurs; that means the incrementation has to happen first.
-
With
gcc(version 3.4.4) it doesn't work,iremaining0forever. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain ClarkeBut not so with gcc version 3.2 (mingw special 20020817-1)
-
st0le wrote:
The fact that it makes sense
Makes sense in the fact that it compiles and does not break anything? ;P
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out nowleppie wrote:
it compiles and does not break anything
Two big qualities indeed. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
-
How could it do that? The operator's function has to end (return) before the assignment occurs; that means the incrementation has to happen first.
liquidplasmaflow wrote:
the incrementation has to happen first
says who? the autoincrement is not necessary in the expression evaluation, and hence it can be scheduled before or after the assignment operator, that is why the net result is undefined. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
-
Isn't the question just whether the runtime environment first assigns the old value. I really thought this would just eventually increment the variable. Because it should normally first assign the old value to i, and then increment i. Why should it ever store the old value somewhere first, then increment i, then put that old value back in i? I know I'm wrong, cuz as said before C# gives an infinite loop, but still it's weird.
I agree. If the code would look like this:
a = i++;Then a would be assigned the value of i and i would be incremented after that, so I would expect in given case that in first iteration i would be assigned value of 0 then i would be incremented. Weird indeed. -
liquidplasmaflow wrote:
the incrementation has to happen first
says who? the autoincrement is not necessary in the expression evaluation, and hence it can be scheduled before or after the assignment operator, that is why the net result is undefined. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
C++'s operator ++ is a function. Last I checked, a function can't do anything after it returns :)
int& operator++(int& argument, int) { int return_value = argument; argument += 1; return return_value; }Am I right? -
C++'s operator ++ is a function. Last I checked, a function can't do anything after it returns :)
int& operator++(int& argument, int) { int return_value = argument; argument += 1; return return_value; }Am I right?Hi, the autoincrement operator may be implemented as a function, I don't think it has to; in C it typically is not. And even when it is a function, it could be inlined automatically, and the instructions then can be rescheduled by the compiler, so there is no way you can predict which one (the final store, or the autoincrement) will occur last and hence prevail; all that in accordance with the legalese language specs PIEBALD showed us. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
-
Hi, the autoincrement operator may be implemented as a function, I don't think it has to; in C it typically is not. And even when it is a function, it could be inlined automatically, and the instructions then can be rescheduled by the compiler, so there is no way you can predict which one (the final store, or the autoincrement) will occur last and hence prevail; all that in accordance with the legalese language specs PIEBALD showed us. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
I'd be interested to know how early versions of C would handle it. I expect the increment should happen first (if indeed it's handled by a hardware instruction), then the original value assigned back, yielding the infinite loop.
-
I'd be interested to know how early versions of C would handle it. I expect the increment should happen first (if indeed it's handled by a hardware instruction), then the original value assigned back, yielding the infinite loop.
I have used dozens of C compilers over the years, most if not all of them did not care about the ambiguity, but simply evaluated the entire expression including side-effects before storing the result. It is only with the advent of RISC and advanced instruction scheduling that things got unclear, and the undefined stuff got introduced. Anyway, I learned long ago not to write code that would be ambiguous or just difficult to read and understand, so it never really mattered ... What is the point of studying a page of rules to make sure something is/isn't ambiguous or undefined, where one could add an intermediate statement or a pair of parentheses? It isn't APL or Lisp after all. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
-
liquidplasmaflow wrote:
the incrementation has to happen first
says who? the autoincrement is not necessary in the expression evaluation, and hence it can be scheduled before or after the assignment operator, that is why the net result is undefined. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
It seems assigning the value of an incremented variable to itself overrides the increment operation. If not, it wouldn't actually matter in which order the operations are executed as the result would be the same: increment comes first: i = 0 // i = 0 i++ = 1 // i = 1 i = i // i = 1 result: 1 assignment comes first i = 0 // i = 0 i = i // i = 0 i++ // i = 1 result: 1