6 ms·

also ++C is faster

by frozenport 5y ago

also ++C is faster

zarzavat 5y ago
Only C++ programmers will appreciate this joke.
savolai 5y ago
Thank you for laughter.
willbudd 5y ago
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.

also ++C is faster

zarzavat 5y ago

Only C++ programmers will appreciate this joke.

savolai 5y ago

Thank you for laughter.

willbudd 5y ago

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.