That is a good point, asadullah.ansari. But your original post seemed to be about built-in types. The "reason" given seemed to be assembly code differences, not actual user code differences.

But of course in a user type, a post-inc is defined something like:
Code:
User User::operator++( int ) { /* Variable name not needed!! */
    User tmp = *this;
    member++;     /* Whatever increment semantics you need */
    return tmp;
}
In that case, a post-inc is potentially ridiculously slower. But if it is your own class, then you will be aware of that. If it is a library object, however, you should be aware of the potential cost, which, if significant, should be in the class documentation.

As for the original post generally, I agree with Salem that most of this is best left to the compiler until it is proved necessary. If your loop calls a function, so what? How much time is really wasted?
It could be anywhere from unnoticable to intolerable since the more work the function actually does, the less significant the overhead as a fraction of the total cost.

Compilers are not (entirely) stupid. They know that a function call has overhead and balance that against the length of the function and potentially inline it.

In point 4 I assume you meant "power", not "multiple", of 2. I can't imagine anyone using pow to calculate powers of 2, but clearly bitshifting is much faster.

Point 5 is hideously incorrect! The most important aspect of program speed is size (of program and especially data). If more can fit into the CPU cache, it will run faster. Besides, array offsets are calculated using multiplication, not powers.

Last edited by oogabooga; 22Jan2008 at 02:50..