The Weird and The Wonderful

mov eax,[_i] ; Fetch value before increment
inc dword [_i] ; Do increment
mov [_i],eax ; Store fetched value

supercat9 wrote:

Wouldn't a more efficient implementation be to simply do nothing, given the lack of a sequence point between the increment and the assignment? Not that I'd generally expect a compiler to find that optimization, but I would have expected code like: mov eax,[_i] ; Fetch value before increment inc dword [_i] ; Do increment mov [_i],eax ; Store fetched valuewhich would, of course, effectively do nothing.

BTW, is there any guarantee about the behavior of "do_something(var++)" if do_something references var? What about "i=++i"? Even though it's hard to imagine that "i=++i;" would do anything other than increment "i", I don't think there's any guarantee that it won't?

CurtD wrote:

do_something(var++) is going to push the current var on the stack, call do_something, then inc var. Nothing strange about that.

CurtD wrote:

This code doesn't "do nothing"

supercat9 wrote:

If the variable i is equal to five before the statement, "i = i++;" is executed, would it not be legitimate for the compiler's generated code to read i (five), increment i (yielding and storing six), and then store the read value back to i (setting it back to 5)? If the variable i is not volatile, would not a legitimate optimization thus be to eliminate the statement altogether?

supercat9 wrote:

Out of curiosity, I wonder if there are any compilers which do not always update a variable used with a pre-increment before making use of the pre-incremented value? It's possible to contrive examples where the optimal code would in fact use (var+1) in the expression and then later store the incremented value to the variable, but I doubt compilers would find such optimizations.

void donothing()
{
   int i = 5;
   i++;
}

supercat9 wrote:

Somewhat, but it's easier to limit the effect of catch-and-ignore to a single statement. Realistically, there are quite a few circumstances in which if an error happens very often the developer should be made aware of it, but beyond that there's no particularly useful action the code can take in response to an error.

Thomas Weller wrote:

If something like an empty try/catch is discovered in code that I am in charge of (and believe me, I will discover it, thanks to FxCop), I will refuse to accept it for production code.


If an error happens and absolutely no action can or should be taken (a very rare case), then at least the exception has to be logged and there has to be a comment in the code that explains why it's OK to just "swallow" the exception in this special case. This is the very least for good code...

Regards
Thomas