H
Helge Jensen
For any type T, post and prefix increment must (roughly) the following
definition, exemplified as something rather similar to an iterator here:
struct T {
T(const T& t_): /* copy state */ {}
const T& operator=(const T& other)
{ /* copy state*/ ; return *this; }
void next() { /* move to next position */ }
const T& operator++() { next(); return *this; }
const T operator++(int) { T old(*this); next(); return old; }
}
The difference is
- a copy-construction of T -- T::T(const T&)
- a return-by-value of T -- T:
perator=(const T&)C++ allows the compiler to replace the return-by-value with a
copy-construction into space allocated by the caller, and is also
allowed to remove the double copy-construction resulting after the
previous optimization. This means that in general the effective
difference is:
- copy-construction of T -- T::T(const T&)
If the *definition* of T::T(const T&) is available at the call-site of
T:
perator++(int) then *that* is a candidate for futher optimization,so the difference mostly hinges on:
- the expense of T::T(const T&)
- the compilers ability to do optimizations, especially on T::T(const T&)
Since most iterators are implemented as thin wrappers around pointer
manipulation, and declared inline, using ++i or i++ as statements
doesn't matter to performance at all, even on iterators. So don't expect
the performance of your program to change because you change from i++ to
++i.
That, however, is not really a good reason to just using i++ generally.
If you think "i++" is a more readable *statement* than "++i" -- that's
fine by me, but consider whether
for (IT it = begin; it != end; it++)
is really more readable than
for (IT it = begin; it != end; ++it)
or if it's just that you've always just seen: "i++" and thus like it to
stay that way.
