Incrementing iterators: ++it more efficient than it++?

Question

Possible Duplicate:
Is there a performance difference between i++ and ++i in C++?

I am writing a program where an iterator is used to loop through a std::vector. Somebody told me that doing ++it in the for statement leads to more efficient code. In other words, they are saying that:

for ( vector<string>::iterator it=my_vector.begin(); it != my_vector.end(); ++it )

runs faster than

for ( vector<string>::iterator it=my_vector.begin(); it != my_vector.end(); it++ )

Is this true? If it is, what is the reason behind the efficiency improvement? All it++/++it does is move the iterator to the next item in the vector, isn't it?

Answer 1

Sometimes yes. With some it will be optimized away and be the same. For std::vector<> (and other std-iterators) it will most likely be optimized to be the same.

Answer 2

Yes. As far as I remember, ++it is more efficient than it++, because it++ creates a temporary object, while ++it does not.

Answer 3

yes ++it is more efficient because it++ need to return a copy of the object then increment itself.

Answer 4

The reason behind the preincrement being faster is that post-increment has to make a copy of the old value to return. As GotW #2 put it, "Preincrement is more efficient than postincrement, because for postincrement the object must increment itself and then return a temporary containing its old value. Note that this is true even for builtins like int."

GotW #55 provides the canonical form of postincrement, which shows that it has to do preincrement plus some more work:

T T::operator++(int)
{
  T old( *this ); // remember our original value
  ++*this;        // always implement postincrement
                  //  in terms of preincrement
  return old;     // return our original value
}

As others have noted, it's possible for some compiler to optimize this away in some cases, but if you're not using the return value it's a good idea not to rely on this optimization. Also, the performance difference is likely to be very small for types which have trivial copy constructors, though I think using preincrement is a good habit in C++.

Answer 5

Closely related to these other questions:

• http://stackoverflow.com/questions/561588/what-is-more-efficient-i-or-i-closed
• http://stackoverflow.com/questions/24901/
• http://stackoverflow.com/questions/484462/

Answer 6

There is a chance that it++ will create a temporary copy.

Also, in C++, there is a chance that someone has overloaded the postincrement operator.

Both of these things could decrease performance vs preincrement. Neither is likely to matter in practice. The temporary copy, in particular, will be optimized away by most compilers since there are no side effects in the 3rd expression of your For loop.

Answer 7

It's unlikely to make any difference for a vector.

In general, ++it is extremely unlikely to be slower than it++ (assuming a sensible implementation, if they're overloaded), and just might be faster. The reason is that if the iterator class itself is at all complex, then because it++ has to return the value before it is incremented, the implementation will generally make a copy.

Vector iterators are probably "just pointers", and both operator++s will be inlined, and as the return value is unused the copy will typically be elided. So it won't make any difference. I'm in the habit of typing ++it because:

1) Some day it might make a difference, for some iterator type, and I don't want to have to do something special for that type.

2) Personally I think the prefix operator more clearly expresses the intent: "increment it", as opposed to "use it and then increment".

Answer 8

it++ performs the following operations:

1. create a copy of of it
2. increment it
3. return the original (non-incremented) it

++it performs the following operations:

1. increment it
2. return it

Because it++ creates a copy, it can be said to be "faster". However, any decent compiler will optimize this difference out for most defined types. For some user-defined types it can be faster.