Preceding Increments/Decrement

Joined
Feb 22, 2006
Messages
1,520
Reaction score
0
I can't seem to quite figure out the difference between a post ++ ($i++) and preceding ++ (++$i).

I had an interview today and my interviewer threw this at me and I never even knew it existed lol. I see there's some kinda of delay, but I was hoping someone could elaborate upon this. The only explanation I can find of this is copied all over from tizag.
the variable does reflect the addition immediately
Kinda vague...
 
With post, the value is applied before the increment, and vice versa:
Code:
x = 0
print x++
prints 0, while with a pre-increment it would print 1. In both cases, x will result in value 1. They have absolutely no difference if you make the increment on a separate line, which is also the safest way.
 
Last edited:
int x;

++x;
x++; <-- the effect of both is the same. But ++x; is faster.

In reality, they'd probably be both compiled the same and be identical, because it's just an 'int'.

But for custom/complex datatypes, pre-increment is faster.

To understand it better, consider the actual function that would do the pre/post increment.

...The pre-increment does:
1) Increment the value passed
2) Continue... (compare, use elsewhere, etc)

...The post-increment does:
1) Creates a NEW copy of the value passed
2) Increments the NEW copy
3) Continue... (compare, use elsewhere, the OLD value)

...
Code...

x=0;
if (++x > 0) { ... } // Resolves to TRUE
...Pre-increment...
x is set to 1, then compared >0.

..or..

x=0;
if (x++ > 0) { ... } // Resolves to FALSE
...Post-increment
The statement begins and a new copy of "x+1" is created
The old "x" is compared to >0
The statement ends and only the "x+1" new copy now exists

...With "int" it's a stupid example because the compiler will understand and optimize it... but for a complex class that overrides the ++ operator, it makes a huge difference :)
 
...but for a complex class that overrides the ++ operator, it may make a slight difference :)
Fixed! :)

Sorry, I just can't get over how ridiculous all these micro-optimizations sound when in reality much, much more is lost by poor choices on higher levels. :sleep:

I actually didn't realize they may have any difference whatsoever (speed wise), now that I read up on it, want to try and guess how hard it will be after over 10 years of i++ to try and throw the ++ on the other side? :laugh:
 
Well, what if the class allocates memory or resources? Each of those operations is relatively slow, like 10000x slower than just a simple addition.

So if you're using Object++ all the time, and each time it's creating a new class for you, that's WAYYYYYY slower than ++Object.

Buttttttttttt whatever :)
 
Well, what if the class allocates memory or resources? Each of those operations is relatively slow, like 10000x slower than just a simple addition.

So if you're using Object++ all the time, and each time it's creating a new class for you, that's WAYYYYYY slower than ++Object.

Buttttttttttt whatever :)
Sure, I don't disagree with bad being bad, just when you put it into context 10,000 operations vs 1 is still little beside all the operations that are needed in a program.

Thanks for pointing out the difference. Don't know how many years I would've continued using postfix where I could go with pre.
 
If an interviewer asked you the difference between two statements using two incrementation operations at the same time, he/she was an idiot.

++$i used in an expression increments $i THEN uses the resulting value as an rvalue (at least in C++, in PHP it may still be an lvalue or rvalues and lvalues are identical or some ****)

$i++ uses the current value of $i, then after this expression is evaluated, it is incremented.

In languages that permit unary increments like this, it's considered bad style, and in most of them UB, to use something like ++i++ or i++++, if that's valid syntactically. It produces terse code and like I said, in most languages the result is undefined.

It's almost always considered bad-style within a single expression to use multiple sub-expressions that rely upon and modify a variable (and often produces undefined behavior). In C++ this can actually lead to massive errors due to the only requirement of function calls and their arguments is a single [ame=http://en.wikipedia.org/wiki/Sequence_point]sequence point[/ame].

So code like this:
$i += $i++ + ++$i;

Should be avoided. There's very little "speed" advantage any of these terse uses will produce, if any (almost never any, except when the language is interpreted like PHP), and so it's usually better to be more explicit about what your code is intended to do.

Also, josh, it's not necessary that post-increment makes a copy. For instance, consider the output of your generic compiler:

Code:
int main(int argc, char** argv){
  int i = 3;
  foo(i++);
  return i;
}

Code:
push ebx;
mov ebx,3;
push ebx;
call foo;
add esp,4;
inc ebx;
mov eax,ebx;
pop ebx;
retn;

In general, an r-value will be used rather than a copy. This just means it'll hold the increment until after the expression, not copy it, increment the original, then use the copy.

And yes, with optimizations it'd probably be:
Code:
push 3;
call foo;
mov eax,4;
add esp,eax;
retn;
 
Last edited:
If an interviewer asked you the difference between two statements using two incrementation operations at the same time, he/she was an idiot.
...
It was me that was unfamiliar with it =(
It's something I've never seen before... I had literally never seen a preceding increment before in nearly 5 years of coding. He completely stumped me when he said, "Oh you should try this instead. Do you know why this works?".
I have always considered i++ to always return i + 1, like i = 0 then i++ would print/echo 1, I just never had a reason or situation to doubt this until this interview lol

The question in the interview had something to do with finding string length and I was told to echo the value of the string. He made me rework the solution several times optimizing it (this guy has a masters in comp sci from Duke). Finally we got an algorithm that was echoing the index of the character, or something like that I can't remember for sure, and my algorithm would return 0 on a length of 1. Either way it was returning 0 when it should return 1; preceding increment was his solution. I was quick to point out that a string of 0 would return 1 as well but he ignored me like he had been as I had pointed out a few flaws he made before as well...

Anyways thanks for the help guys. I'm not sure how much more in-depth we can get on this lol
 
It was me that was unfamiliar with it =(
It's something I've never seen before... I had literally never seen a preceding increment before in nearly 5 years of coding. He completely stumped me when he said, "Oh you should try this instead. Do you know why this works?".
I have always considered i++ to always return i + 1, like i = 0 then i++ would print/echo 1, I just never had a reason or situation to doubt this until this interview lol

The question in the interview had something to do with finding string length and I was told to echo the value of the string. He made me rework the solution several times optimizing it (this guy has a masters in comp sci from Duke). Finally we got an algorithm that was echoing the index of the character, or something like that I can't remember for sure, and my algorithm would return 0 on a length of 1. Either way it was returning 0 when it should return 1; preceding increment was his solution. I was quick to point out that a string of 0 would return 1 as well but he ignored me like he had been as I had pointed out a few flaws he made before as well...

Anyways thanks for the help guys. I'm not sure how much more in-depth we can get on this lol

Code:
int strlen(const char* s){
  if(!s) return 0;

  const char* p = s;
  while(*p++ != 0);
  return (int)p-s;
}

Did you end up with something like that?
 
No I couldn't use strlen and the test was for a palindrome. It wasn't a method/function either, just some code on a page the echo'd true or false. I couldn't use any functions and keep in mind this was in php.
 
Last edited:
Back