Post your code optimizations
- Thread starter KimB
- Start date
Mate Kovacs
Newcomer
I played with G++ for a moment, and it indeed says "error: non-lvalue in increment" on "i = (i++)++" and "2++" as well as on "++2". It doesn't like "i++ = i" either ("error: non-lvalue in assignment").Mate Kovacs said:
But as it turns out, things like "++i = 2", "(++i)++" and "int *p = &--i" are legal
, so the pre[++/--] operators seem to return a reference to the argument.EDIT: GCC doesn't like the "strange stuff", so I guess it's not valid C code.
Last edited by a moderator:
Well, the timing of when pre-increment and post-increment are executed isn't defined, so post increment can indeed be evaluated before the rest of the statement is executed (this probably isn't done for built-in types, for performance reasons, but may be for other types).DiGuru said:
Here's an example of how these are overloaded:
http://www.cs.bu.edu/teaching/cpp/overload/incr-op.html
Notice that the pre- and post- increment operators are completely different function calls, with the return value set by the function, such that one might expect the following:
x = 1;
x += x++ + x++;
...to result in x = 6. That is, if the evaluation order is left to right, we can incrementally replace the functions by their return values, recording the value of x at each step:
x += x++ + x++; (x = 1)
x += 1 + x++; (x = 2)
x += 1 + 2; (x = 3)
(x = 6)
Instead, if the compiler doesn't evaluate the ++'s until after the statement, for the purpose of performance (which seems likely), then the result would be x = 5.
edit:
Yes, if I use the integer type for the above statement, the resultant value for x is 5. If I make a little integer container class and overload the above operators, the return value is 6.
That makes sense. You can't return a reference with the postfix operators, since the value has already changed, and you don't want to return the changed value.Mate Kovacs said:But as it turns out, things like "++i = 2", "(++i)++" and "int *p = &--i" are legal
rendezvous
Regular
you shouldMate Kovacs said:
have a look at lint by gimpel software (IIRC). I am not sure if it warns you for unfeined behaviour due to undefined evaluation order, but i would suspect that it does. highly recomended.
http://www.gimpel.com/
edit: added link, the "bug of the month" archive on gimpel's site is fun to read too.
Last edited by a moderator:
Conceptually:DiGuru said:
Code:
// preincrement
int& operator++(int& i)
{
i += 1;
return i;
}
// postincrement
int operator++(int& i, int dummy_to_make_this_postincrement)
{
int returnvalue = i;
i += 1;
return returnvalue;
}Postincrement cannot return a reference, because it's whole point is to return a different value from the one it has modified.
Yes, but it should increment the variable *after* the statement is executed. That's the whole idea about it. And no matter if that variable changed in the execution of the statement, or where you put it. Just execute the expression, take the original lvalue and increment the rvalue.Xmas said:
diGuru:
That's your interpretation, but it's not what the spec says.
This is not about sloppy compilers, they do exactly what the specification intended. That is, the specification intensionally left it up to the compiler to do the actual increment whenever it wants (beteen use and end of statement). In many cases it makes most sense to do the increment directly (you already have the value in a register, and maybe a pointer to the place it should be stored). In some cases it's best to wait until the whole expression is calculated (extremely register limited).
So whenever doing a X++ or ++X, don't touch X in the same expression (and that includes the left hand side of assignements).
That's your interpretation, but it's not what the spec says.
This is not about sloppy compilers, they do exactly what the specification intended. That is, the specification intensionally left it up to the compiler to do the actual increment whenever it wants (beteen use and end of statement). In many cases it makes most sense to do the increment directly (you already have the value in a register, and maybe a pointer to the place it should be stored). In some cases it's best to wait until the whole expression is calculated (extremely register limited).
So whenever doing a X++ or ++X, don't touch X in the same expression (and that includes the left hand side of assignements).
Code:
i = 2;
i *= i++;
// Could be:
i = 2;
iTemp = 2;
i++; // => 2+1 = 3
i *= iTemp; // => 3*2 = 6
// or:
i = 2;
iTemp = 2;
i *= iTemp; // => 2*2 = 4
i++; // => 4+1 = 5Yes, I get that. But, if you're designing a language, do you try to make it hard (inconsistent) on the developer to perhaps save a few cycles here and there, or do you want to be consistent?Basic said:
That's why people react so strong to things like this.
Xmas said:
But that's the opposite of what you wanted out of C. You wanted C to increment the value at the end of the statement.DiGuru said:
I'd say that it's an error prone and bad coding style to use expressions with side effects together with the variables it changes in the same expression. So if there's an error in the syntax, then it's that it allows it at all.
Yes, I agree. That would be best, and C# isn't doing that either. But at least it's consistent. I'll settle for that, given the choice. But both ways are sloppy, IMO. That's why I like Delphi (Object Pascal) best. It always does what I expect it to do, unless I make logic errors, of course.Basic said:
Edit: it doesn't have operator overloading, templates or all the other stuff that created those inconsitencies in the first place either. Which might just be why I like it.
Last edited by a moderator:
Operator overloading can be so nice for making readable code, though. It has to be done right, of course, but can be a fantastic help.DiGuru said:Edit: it doesn't have operator overloading, templates or all the other stuff that created those inconsitencies in the first place either. Which might just be why I like it.