4 ms·

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 t

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
- makapuf 5y ago
  That is increment a part, for whatever is being defined as incrementing for this class. If you define different things for post and pre increment they will cost differently, sure. If the compiler decides to do more than what I told to, it will be longer. But will a++ always cost more than ++a?
  - jcelerier 5y ago
    > If you define different things for post and pre increment They are defined as different things. One returns the current value and increments, the second increments the current value and returns it. In the first case you have to cache the previous value, in the second you don't. If your operators don't do that they are bugged and wrong.

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

makapuf 5y ago
That is increment a part, for whatever is being defined as incrementing for this class. If you define different things for post and pre increment they will cost differently, sure. If the compiler decides to do more than what I told to, it will be longer. But will a++ always cost more than ++a?
- jcelerier 5y ago
  > If you define different things for post and pre increment They are defined as different things. One returns the current value and increments, the second increments the current value and returns it. In the first case you have to cache the previous value, in the second you don't. If your operators don't do that they are bugged and wrong.