5 ms·

You jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where

You jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where they simply occur as stand-alone expressions, despite their obvious semantic equivalence. Even stranger: people that insist on writing their (loops; like; ++this) in 2021 as if doing so is in any way superior or something.

vbezhenar 5y ago
Optimizing integer increment might be easy. Hard thing is optimizing overloaded increment operator. ++c is naturally faster, because it does not have to make a copy of its previous value. Especially if that operator implementation is inside another library. So it makes sense to use fast-by-default approach.
- willbudd 5y ago
  Yeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.
deleted 5y ago
[deleted]
jcelerier 5y ago
With complex iterator types that carry additional state themselves (for example think iterators to sparse data or generators), it definitely makes a difference
- makapuf 5y ago
  a++; means do nothing then increment a, ++a means increment a then do nothing, what should be the difference? (Of course you can define operator++ to format the hard drive. )
  - IcePic 5y ago
    If you have a single-pass compiler (for speed) then it will not know on pass #2 that the old value is to be used for something or not and can drop it. In a single-pass run, you must generate code to keep the previous value in case the line actually was foo = ++a; or foo = a++; so that foo gets the pre-inc or post-inc value. The small part that creates the code for the small "a++" part of the line will then produce a dead store of the pre-inc value, and no 2nd pass will remove it.
  - ohgodplsno 5y ago
    Allow me introduce operator overloading, where I have suddenly defined a ++ operator on my god object that contains a 50MB pool. This operator increments a single field in it, and I really need it because I do it so often. ++godobject will simply increment that value. godobject++ will make a copy of that object, returning it to you along with allocating another 50MB pool, purely to increment the value.
    - makapuf 5y ago
      That's what I meant with operator++ being redefined to do anything.
      - jcelerier 5y ago
        but when you write generic algorithms (as you should), you don't know beforehand with which "operator++" your a will be called. So you have to go for the one which will give the best performance.
  - jcelerier 5y ago
    > a++; means do nothing only if a is a very simple thing. plenty of "advanced" containers actually do things ; in the "a++" case they have to save the previous state to return a copy, in the "++a" case they don't. If your iterator for instance contains a std::vector<int> to maintain some internal state for a multidimensional dynamic matrix, then in one case you'll get a simple increment, in the other a whole dynamic allocation / free which may be optimized out by the compiler in release mode and definitely won't in debug mode

vbezhenar 5y ago

Optimizing integer increment might be easy. Hard thing is optimizing overloaded increment operator. ++c is naturally faster, because it does not have to make a copy of its previous value. Especially if that operator implementation is inside another library. So it makes sense to use fast-by-default approach.

willbudd 5y ago
Yeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.

deleted 5y ago

[deleted]

jcelerier 5y ago

With complex iterator types that carry additional state themselves (for example think iterators to sparse data or generators), it definitely makes a difference

makapuf 5y ago
a++; means do nothing then increment a, ++a means increment a then do nothing, what should be the difference? (Of course you can define operator++ to format the hard drive. )
- IcePic 5y ago
  If you have a single-pass compiler (for speed) then it will not know on pass #2 that the old value is to be used for something or not and can drop it. In a single-pass run, you must generate code to keep the previous value in case the line actually was foo = ++a; or foo = a++; so that foo gets the pre-inc or post-inc value. The small part that creates the code for the small "a++" part of the line will then produce a dead store of the pre-inc value, and no 2nd pass will remove it.
- ohgodplsno 5y ago
  Allow me introduce operator overloading, where I have suddenly defined a ++ operator on my god object that contains a 50MB pool. This operator increments a single field in it, and I really need it because I do it so often. ++godobject will simply increment that value. godobject++ will make a copy of that object, returning it to you along with allocating another 50MB pool, purely to increment the value.
  - makapuf 5y ago
    That's what I meant with operator++ being redefined to do anything.
    - jcelerier 5y ago
      but when you write generic algorithms (as you should), you don't know beforehand with which "operator++" your a will be called. So you have to go for the one which will give the best performance.
- jcelerier 5y ago
  > a++; means do nothing only if a is a very simple thing. plenty of "advanced" containers actually do things ; in the "a++" case they have to save the previous state to return a copy, in the "++a" case they don't. If your iterator for instance contains a std::vector<int> to maintain some internal state for a multidimensional dynamic matrix, then in one case you'll get a simple increment, in the other a whole dynamic allocation / free which may be optimized out by the compiler in release mode and definitely won't in debug mode