Right, the final semicolon is extraneous. Also, since nobody is using the pre-increment value of your incremented variable, you should use the pre-increment form (it compiles to ever so slightly faster code):

Buub wrote:Right, the final semicolon is extraneous. Also, since nobody is using the pre-increment value of your incremented variable, you should use the pre-increment form (it compiles to ever so slightly faster code):

It makes me look like an idiot, asking somebody else when the solution is so trivial, but I find that at least I know what I did wrong in the end.

EDIT: I knew about the pre-increment, but didn't think it would be useful at all, so I always use the post-increment to keep things simple in my head. The loop will probably run... for as many times as one needs frames in a DICOM Secondary Capture Multiframe file. At max 1000 I'm sure.

Probably, but I have no reason for saying so other than a hunch. (Also keep in mind that the actual semantics of -O3 may depend on the compiler and the CPU architecture...)

As far as which is more "correct" from a coding standpoint, there isn't really a right or wrong answer. IMO the only reason the post-increment syntax is considered the "normal" one is because it is fairly common to use the old value of the index for something. E.g., the following idiom is typical for clearing the first n elements of array a:

Crayon Shin Chan wrote:It makes me look like an idiot, asking somebody else when the solution is so trivial, but I find that at least I know what I did wrong in the end.

No need to feel bad, trivial mistakes happen even to seasoned developers. And sometimes when you read a piece of your own code, your brain sees what you *thought* you wrote, not what you *actually* wrote; all it takes is a second pair of eyes.

The years just pass like trains. I wave, but they don't slow down.-- Steven Wilson

Buub wrote:Right, the final semicolon is extraneous. Also, since nobody is using the pre-increment value of your incremented variable, you should use the pre-increment form (it compiles to ever so slightly faster code):

DancinJack wrote:The way he did it was the way I was taught in college. Depending on how many times that for loop has to run, I can't imagine we're talking about much time here right?

The point is it's a nearly free optimization. 99% of your loops it will not be measurable, but it also doesn't cost anything to do anywhere other than developing a habit.

You should not prematurely optimize code, especially if it comes at a cost to normal development, either in development time or more complex code. But if it's literally choosing to put symbols on one side of a variable or the other, there's no reason not to do it.

I find pre-increment less readable. Post-increment is the standard and preincrement makes me think that there is something special being done here. From a performance point of view, I suspect the pre-increment is one of those things that may have been faster on one compiler and processor architecture but is no win or even slower on another. Optimisation rules of thumb often become obsolete, see for example how the removal of Duff's Device from the X server made things run faster: http://lkml.indiana.edu/hypermail/linux ... /0171.html

notfred wrote:I find pre-increment less readable. Post-increment is the standard and preincrement makes me think that there is something special being done here. From a performance point of view, I suspect the pre-increment is one of those things that may have been faster on one compiler and processor architecture but is no win or even slower on another. Optimisation rules of thumb often become obsolete, see for example how the removal of Duff's Device from the X server made things run faster: http://lkml.indiana.edu/hypermail/linux ... /0171.html

Not quite. The reason pre-increment is faster is because the compiler knows that you do not need the pre-incremented value of the variable, and can omit any actions before the increment. When you post-increment, that guarantee cannot be assumed, and the compiler must (unless optimized away) emit the current value of the variable before doing the increment.

Now, no argument that modern compilers might be able to optimize to the same code, but the fact remains that it's a relatively costless habit to form and can result in measurable performance benefits in some cases. And even if the compiler can optimize the code to be identical for simple variables, it still might not be the case if the ++ operators are methods on a class object, where assumptions cannot be made ahead of time, and optimization needs to happen within the ++ operator method.