|
One my friends once wrote
<br />
int i = 0;<br />
<br />
while(i < 10)<br />
{<br />
i = i++;
}<br />
i laughed my ... off. 
The fact that it makes sense, made it more funny...
-st0le [st0le'n'stuff softwarez!]
http://st0lenc0des.googlepages.com/
modified 20-Oct-19 21:02pm.
|
|
|
|
|
That's a subtle horror!
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 Clarke
|
|
|
|
|
ever asked him, what that should do... and what i++ means... sry, i'm curious about it 
(yes|no|maybe)*
|
|
|
|
|
st0le wrote: The fact that it makes sense
Makes sense in the fact that it compiles and does not break anything? 
|
|
|
|
|
leppie 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.
|
|
|
|
|
Perhaps I'm being Captain Obvious but, in plain C at least, the result is undefined. The compiler I'm using at the moment does not leave the loop as i is never incremented.
|
|
|
|
|
I wrote a test application (the code works in VC++ 8, and i stays 0 in VC#), but it seems that I had a mental blockade to enter i = i++; It took me two i = i+1; until I could force my fingers to do that.
Is the result really undefined by ANSI or whoevers specification?
|
|
|
|
|
Doc Lobster wrote: Is the result really undefined by ANSI or whoevers specification?
I think i = i++ might be OK, but apparently i = ++1 + 1 is not.
I'm looking in the ISO/IEC 9899:TC2 document, section 6.5 on page 67.
See footnote 71
"
6.5 Expressions
1 An expression is a sequence of operators and operands that specifies computation of a
value, or that designates an object or a function, or that generates side effects, or that
performs a combination thereof.
2 Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression. Furthermore, the prior value
shall be read only to determine the value to be stored.71)
3 The grouping of operators and operands is indicated by the syntax.72) Except as specified
later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation
of subexpressions and the order in which side effects take place are both unspecified.
4 Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |,
collectively described as bitwise operators) are required to have operands that have
integer type. These operators yield values that depend on the internal representations of
integers, and have implementation-defined and undefined aspects for signed types.
5 If an exceptional condition occurs during the evaluation of an expression (that is, if the
result is not mathematically defined or not in the range of representable values for its
type), the behavior is undefined.
6 The effective type of an object for an access to its stored value is the declared type of the
object, if any.73) If a value is stored into an object having no declared type through an
lvalue having a type that is not a character type, then the type of the lvalue becomes the
effective type of the object for that access and for subsequent accesses that do not modify
71) This paragraph renders undefined statement expressions such as
i = ++i + 1;
a[i++] = i;
while allowing
i = i + 1;
a[i] = i;
72) The syntax specifies the precedence of operators in the evaluation of an expression, which is the same
as the order of the major subclauses of this subclause, highest precedence first. Thus, for example, the
expressions allowed as the operands of the binary + operator (6.5.6) are those expressions defined in
6.5.1 through 6.5.6. The exceptions are cast expressions (6.5.4) as operands of unary operators
(6.5.3), and an operand contained between any of the following pairs of operators: grouping
parentheses () (6.5.1), subscripting brackets [] (6.5.2.1), function-call parentheses () (6.5.2.2), and
the conditional operator ?: (6.5.15).
Within each major subclause, the operators have the same precedence. Left- or right-associativity is
indicated in each subclause by the syntax for the expressions discussed therein.
73) Allocated objects have no declared type.
"
|
|
|
|
|
The code I wrote to test it is:
# include <stdio.h>
int
main
(
int argc
,
char* argv[]
)
{
int result = 0 ;
result = result++ ;
printf ( "%d" , result ) ;
return ( result ) ;
}
(This is the same code I used to test Borland C/C++ 5.5)
compiling this using
DEC C V6.0-001 on OpenVMS Alpha V7.3-2
yields the warning
"
In this statement, the expression "result=result++" modifies the variable "result" more than once without an intervening sequence point. This behavior is undefined.
"
but it compiles and returns 1 when executed.
|
|
|
|
|
It works with Borland C/C++ 5.5
|
|
|
|
|
With gcc (version 3.4.4) it doesn't work, i remaining 0 forever.
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 Clarke
|
|
|
|
|
i wonder what would happen in other languages??
*writes java application*
we've got a Infinite loop here...i=0, all the way  
-st0le [st0le'n'stuff softwarez!]
http://st0lenc0des.googlepages.com/
modified on Tuesday, February 19, 2008 12:24 AM
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Java behaves the same way, i.e. loops indefinitely (or at least, until the hammer comes down).
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 Clarke
|
|
|
|
|
But not so with
gcc version 3.2 (mingw special 20020817-1)
|
|
|
|
|
C# is the same, so, it seems this behaviour is predictable and I will have to read PIEBALD's lengthy excerpt.
|
|
|
|
|
What's happening makes sense. The operator in question is the postfix incrementor; it increments the variable, but it returns the pre-incrementation value. So, it increments itself, but it's being assigned its original value.
|
|
|
|
|
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.
|
|
|
|
|
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
<br />
int& operator++(int& argument, int)<br />
{<br />
int return_value = argument;<br />
argument += 1;<br />
return return_value;<br />
}<br />
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
modified 19-Nov-18 21:01pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
