is ++i faster than i++?

a friend told me that using pre increment is faster than post increment in for loops. Is this true? If so, then why?

Just mentioned it in the other thread...

Quote:

---

Originally Posted by HighCommander4

i++ creates a temporary variable and puts the old value of i into that variable, then increments i. ++i just increments i.

---

It could be faster, it could also be slower, most likely it's just going to be equally fast. It depends on the code preceding/following the increment.

Either way, we are talking a very very absolute minimal amount of change in speed (if any), maybe 1ns (yes, 'nano', not milli :D) at most.

The short answer: Don't worry about it.

The long answer: Both ++i and i++ will most likely be compiled into an 'INC <register>' type instruction. Any speed improvements gained would be a result of what precedes or follows the INC instruction.

Quote:

---

Originally Posted by HighCommander4

i++ creates a temporary variable and puts the old value of i into that variable, then increments i. ++i just increments i.

---

Who tried (and succeeded) to make you believe something as ridicilous as this claim ? :D
A scenario like this might be true for a class with an overloaded ++ operator (depending on how the overload was written), but it certainly isn't true for int's no temporary variable is needed.


++i : increments i, then returns the incremented value
i++ : returns i, then increments i after whatever the return value was used for.


The only reason why a preincrement is sometimes better than a postincrement is to guarantee a result when more than one increment happens on the same variable during a single compound statement as in:

Code:

---

int i=0;
 foo(i++,i++);

---

Behaviour is undefined in this case... It may seem strange, but when compiled in VC++ the above will call foo with the first parameter being 1, the second being 0. i will be 2 at the end regardless.

Why should I use ++i instead of i++?....

Quote:

---

Originally Posted by OReubens

The short answer: Don't worry about it.

The long answer: Both ++i and i++ will most likely be compiled into an 'INC <register>' type instruction. Any speed improvements gained would be a result of what precedes or follows the INC instruction.

---

This above is the C view. In C++ the ++ and -- operators can be overloaded and when they are the postfix forms are inherently slower (because a temporary variable has to be introduced in the overload function). You can as well make a habit of always using ++i (instead of i++) when it doesn't matter to you for some other reasons.

So in C++ the short answer is: Prefer the prefix forms of ++ and --.

Quote:

---

Originally Posted by OReubens

Who tried (and succeeded) to make you believe something as ridicilous as this claim ? :D

---

Well, I guess it was Hurb Sutter that made this ridicilous claim :D according to Hurb it's even true for ints. You might want to look at
this .
Hope this helps,
Regards,
Usman.

Quote:

---

Originally Posted by OReubens

[...] The only reason why a preincrement is sometimes better than a postincrement is to guarantee a result when more than one increment happens on the same variable during a single compound statement as in:

Code:

---

  int i=0;
  foo(i++,i++);

---

Behaviour is undefined in this case... It may seem strange, but when compiled in VC++ the above will call foo with the first parameter being 1, the second being 0. i will be 2 at the end regardless.

---

How would preincrement help in this case? It's still undefined behaviour, whether you preincrement, postincrement or do a mixture of the two.

Quote:

---

Originally Posted by _uj

This above is the C view. In C++ the ++ and -- operators can be overloaded and when they are the postfix forms are inherently slower (because a temporary variable has to be introduced in the overload function). You can as well make a habit of always using ++i (instead of i++) when it doesn't matter to you for some other reasons.

So in C++ the short answer is: Prefer the prefix forms of ++ and --.

---

Yes, like I said before, with classes I would agree that usually a postincrement can be made more optimal. But it all depends on how the class operator is written.

However the question here was 'i++' vs '++i', which means incrementing an int. and in that respect both are equally fast.

In fact, the postincrement will usually be slightly faster than preincrement because of the way the CPU reacts to an address/index being changed prior to it being used.

Quote:

---

Originally Posted by usman999_1

Well, I guess it was Hurb Sutter that made this ridicilous claim :D according to Hurb it's even true for ints. You might want to look at
this .

---

The increment refered to in this instance sample is an increment on an iterator class. And this may indeed be slower. when overloading operators. anything can happen. The ++ operator isn't even required to increment anything. It may just as wel be an 'abuse' to achieve some other effect on the class.


On an int it is most likely not to make a difference. Although I have had cases where post incrementing an int yielded a slightly better result than pre incrementing. In fact. I have never had to change a postincrement (on an int) into a preincrement to get better code, while I have had to do the reverse on several occasions. But the cases are rare anyways.

Quote:

---

Originally Posted by Graham

How would preincrement help in this case? It's still undefined behaviour, whether you preincrement, postincrement or do a mixture of the two.

---

:o erhm. well. erhm. You got me there... to an extent...I guess...
While behaviour is defined in this case (according to my interpretation), it wasn't exactly the behaviour I was expecting either. Both parameters to foo() will be 2 (I was expecting 1,2 at first).
This behaviour does seem to be consistent for the 6 compilers I tried. While the postincrement got me different results... I got these:
0,0
1,0
0,1

Then again, I never write code like this anyway. I have this absolute horror of C/C++ code where an attempt was made to write as few code as possible and try to have a single compound statement do as much as possible.
Some programmers actually expect the compiler to produce better code for this too! While it may have been true in the early days of the C compilers, it no longer holds true for the optimizing ones.
All it really does is make the code less readable, and more difficult to debug.

The Standard says this (Section 5, para 4)

Quote:

---

Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression.

---

Any attempt to increment the same variable twice between sequence points is undefined behaviour.

Quote:

---

Originally Posted by Graham

The Standard says this (Section 5, para 4)Any attempt to increment the same variable twice between sequence points is undefined behaviour.

---

Ok, so it's undefined as well... :D
It's another thing I can add to the list of items in the "avoid complex code" 'war' we have to repeat almost each time we get a new programmer on the team.

Quote:

---

Originally Posted by OReubens

However the question here was 'i++' vs '++i', which means incrementing an int. and in that respect both are equally fast.

---

How do you know i is an int? That's something you're presuming only.

It's quite natural presumption in context...

BTW, is the behaviour of something like
int a=(5,6,7);
predictable? I thought that all lists separated by comma are being actualizing right-to-left, so when using function with parameters containing, say, other functions calls, those calls would be preceeded in right-to-left order. It seems now that there is no such rule...