2

I read somewhere using a post increment /decrement operator is much better than a normal operator.if so, i wanted to know and how it is more efficient?

jww
  • 97,681
  • 90
  • 411
  • 885
  • 4
    In Java, how much more trivial can you get than adding one int to another. What efficiency would you really imagine? – Scary Wombat Jul 29 '14 at 00:50
  • 1
    @Scary - in a class, it can matter. I believe that's why pre-increment it is preferred over post-increment. I believe its mentioned in, for example, [Google's C++ Style Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml). – jww Jul 29 '14 at 00:51
  • 1
    In C and C++, probably don't, years ago, there is a difference that post and pre increment, map directly to an cpu instruction `add [reg or addr], 1`. This days the performance is the same adding 1 or any other value of word size. This are made by hardware. – NetVipeC Jul 29 '14 at 00:52
  • 1
    Here's a good analysis of C++ and {pre|post}-increment. It does not make a comparison on normal "+" though, and it does not compare against Java. [Post Increment and Pre Increment concept?](http://stackoverflow.com/questions/4445706/post-increment-and-pre-increment-concept). – jww Jul 29 '14 at 01:00

2 Answers2

3

For numbers, ++i is exactly identical to i += 1, and i++ is similar to tmp = i, i += 1, tmp (assuming C semantics for ,). So don't worry which operator you're using, in such cases.

For C++ class objects that have user-defined operators for ++ and +=, the performance is, of course, dependent on the specifics of the operators' implementations. Note that in C++ code, + is usually defined in terms of += (and postincrement is usually defined in terms of preincrement), so prefer to use += and preincrement ++ unless you need to do a nondestructive addition or use the original value before incrementing, respectively.

Sample implementation of + in C++ (note that lhs is passed by value so that it is copied, so that the += does not change the original object):

Foo operator+(Foo lhs, Foo const& rhs)
{
    return lhs += rhs;
}

Sample implementation of postincrement in C++:

Foo Foo::operator++(int)
{
    Foo orig(*this);
    ++*this;
    return orig;
}
C. K. Young
  • 219,335
  • 46
  • 382
  • 435
  • 1
    The inc instruction is smaller than the add instruction in x86, but I'd be surprised if anyone cared these days, and doubly surprised if it had any performance impact, and triply surprised if compilers weren't able to figure out which one to use. – zneak Jul 29 '14 at 00:54
  • @zneak Exactly, which is why for numbers, it really doesn't matter. For user-defined classes in C++, however, it does matter because the compiler has more-limited freedom in what it can optimise away. – C. K. Young Jul 29 '14 at 00:56
  • The compiler in most of the case can analyze if the return value by the post increment is used, if not optimize as if were pre-increment. The other problem with new compiler is data dependency, when using pre-increment the cpu has to wait for the result of the operation to use the value in other instructions, with post increment, it could continue execution until the value is needed, all this in parallel. – NetVipeC Jul 29 '14 at 00:57
  • @zneak even though inc is smaller, add 1 will be atleast as fast if not faster http://stackoverflow.com/questions/13383407/is-add-1-really-faster-than-inc-x86 – vandale Jul 29 '14 at 01:00
  • 1
    @NetVipeC: Only if it can prove post- and pre-increment are (disregarding return value) identical, like for all builtin types. – Deduplicator Jul 29 '14 at 01:48
  • On most modern processors, an integer add is a one cycle operation. How could increment be faster? – Patricia Shanahan Jul 29 '14 at 06:45
1

For Intel X86 CPUs there's not much advantage if any. There are some CPUs that have pre and post increment options for registers used as addresses on memory loads, stores, moves, ... , and in these cases, the pre and post increment operators would be better, assuming that the compiler wouldn't optimize code without pre and post increment to end up using the CPUs pre and post increment features anyway.

rcgldr
  • 27,407
  • 3
  • 36
  • 61