2

I heard a professor saying "Avoid postfix operator where the context allows to choose prefix". I search but I didn't found related posts in stackoverflow that explaining this.

Why to prefer prefix operator++ to postfix operator++ when we have the ability to choose either one?

Avraam Mavridis
  • 8,698
  • 19
  • 79
  • 133
  • 4
    http://stackoverflow.com/questions/3181211/prefix-postfix-increment-operators and it is mainly to avoid copying the object with postfix operator – fatihk May 22 '13 at 15:37
  • Your professor is micro-optimizing prematurely. He is also citing and old adage that is now largely out-of-date with modern compilers. – John Dibling May 22 '13 at 15:41
  • @JohnDibling It was out-of-date when the STL was first proposed. Even the oldest C++ compilers did the necessary optimizations. – James Kanze May 22 '13 at 15:44
  • See [this SO post](http://stackoverflow.com/questions/24901/is-there-a-performance-difference-between-i-and-i-in-c). – wmorrison365 May 22 '13 at 15:45

5 Answers5

7

The prefix operator++ does a single operation -- increment the value.

The postfix operator++ does three operations -- save the current value, increment the value, return the old value.

The prefix version is conceptually simpler, and is always (up to bizarre operator overloads) at least as efficient as the postfix version.

Mankarse
  • 39,818
  • 11
  • 97
  • 141
  • You say that "postfix ++ **does** 3 operations," but this isn't the case if the compiler can optimize them away. – John Dibling May 22 '13 at 15:52
  • 3
    @JohnDibling: The issue isn't the performance. The issue is that the code is asking for something that it doesn't need, which is confusing. – Mankarse May 22 '13 at 15:53
  • Excellent point. This clarifies in my mind my own rule of thumb for pre/postfix -- there is no rule of thumb. Know what they both do, and use the one you need. – John Dibling May 22 '13 at 15:56
3

I'm pretty sure your professor is talking about the old speed difference between the prefix and postfix ++ operator. I'm also pretty sure it no longer matters which you choose as modern compilers usually are smart enough to recognize if it can be optimized out.

Also, depending on your code you might be required to use one or the other for correctness.

greedybuddha
  • 7,488
  • 3
  • 36
  • 50
  • I don't think it ever mattered. The STL is predicated on the premise that copying an iterator is a trivial operation, and back when Herb first brought up this point, I actually measured. At the time, I expected a small difference for some of the more complex iterators (a reverse iterator on a map, for example), but no... The performance difference is yet another of those performance myths. – James Kanze May 22 '13 at 15:43
  • `struct Foo { Foo operator++(int); Foo& operator++(); Foo(Foo const&); }` -- do you see the difference in the postfix and prefix signature that could result in a large difference in performance? It is true that most iterators won't have such a difference, and if inlined the compiler could notice that the copy can be discarded, bit I can sure write a class that must be much, much slower with postfix++ than prefix. – Yakk - Adam Nevraumont May 22 '13 at 15:43
  • Yakk, this is not going to tell you the performance difference after compiler optimization. – greedybuddha May 22 '13 at 15:45
  • @greedybuddha: No, but it tells you that prefix should be no slower and might be faster. So why not just use it rather than arguing about it? – Mike Seymour May 22 '13 at 15:57
2

The prefix operator is potentially faster than the postfix operator, depending on the type on which it's operating. It should never be slower.

For most intrinsic types, the speed should be identical. However, many custom iterators need to make an extra copy of some state object in order to properly implement the postfix operator.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
0

In order to implement the postfix operator, a copy of the original object has to be taken because that's what gets returned back to you.

For the prefix operator, you get the new object back, saving the copy overhead.

Some folk (rightly) will tell you that the compiler will optimise out unintentional postfix copies; for example in code like for (int n = 0; n < large; n++)

I'd always prefer to see ++n.

Infact, I'd rather the language be called ++C; not C++!

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
-1

There's no real reason, except for stylistic issues. One noted specialist recommended it once, and everyone blindly followed, although the measures I did indicated that it made no difference.

If you're starting on a green fields project, I'll use prefix, but the motivation is just to avoid stupid discussions about the issue. If I'm working on existing code, I'll continue to use whatever was most common, because in real code, it makes absolutely no difference, despite claims to the contrary.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • it makes a difference depending on the context. int i = ++x results in a different value than int i = x++. This is a pretty important difference. – BoldAsLove Dec 03 '18 at 22:54