preincrement vs postdecrement question
Author
ok, this is kinda stupid, but at the same time it's been bothering me for a while. as negligible as it may be in the big picture, isn't ++i faster than i++?
Short answer, it depends.
For naitive types, the optimiser will make them both the same.
If the special use of the a++ isn't used, its transformed into ++a.
If it is, then its kept, and it requires a temperary copy (a couple of bytes on average, VERY fast). and the increment, and the destruction of the temp. (also quick)
From,
Nice coder
For naitive types, the optimiser will make them both the same.
If the special use of the a++ isn't used, its transformed into ++a.
If it is, then its kept, and it requires a temperary copy (a couple of bytes on average, VERY fast). and the increment, and the destruction of the temp. (also quick)
From,
Nice coder
Depends on the type of i, but in general, ++i will be either faster than or the same speed as i++.
++i is executed directly in the code
i++ waits with incrementing till the entire statement is evaluated.
Its not faster but depends on what you want.
example
j is 6 and i is 6
k is 5 and i is 6
i++ waits with incrementing till the entire statement is evaluated.
Its not faster but depends on what you want.
example
int i = 5;int j = ++i;i = 5;int k = i++;j is 6 and i is 6
k is 5 and i is 6
Quote:Original post by Starik1974
++i is executed directly in the code
i++ waits with incrementing till the entire statement is evaluated.
Its not faster but depends on what you want.
example
*** Source Snippet Removed ***
j is 6 and i is 6
k is 5 and i is 6
The previous statement is in ERROR. (sorry starik1974.)
correction:
++i is executed with the statement
i++ is executed Between the current statement and the next!
There exactly the same operation, just at different times. (with the statement, and after it).
for eg. printf(i++) is equal to
printf(i)
++i
Same for all the others
Print(i++,j++,k++,l++) =
++i
++j
++k
++l
They operate at exactly the same speed, just with different timing
From,
Nice coder
The speed question arises because of the fact that post-increment has a side effect. For intrinsic types, the compiler can determine if the side effect is used or not and can convert the post-increment into pre-increment. For iterators, however, or user-defined types, it's impossible to tell what other differences may exist.
Choose which one to use in your code based on clear intention, not superstition about performance. If you don't need the side effect of post-increment, then use pre-increment.
Choose which one to use in your code based on clear intention, not superstition about performance. If you don't need the side effect of post-increment, then use pre-increment.
WTF??? The pre-increment operator SHOULD be the prefered way to increment user-defined types unless you really do want to modify the original object.
Picture this...for whatever reason your user defined type has dynamic memory associated with it. First of all, allocating memory in a constructor is dangerous, what happens if the allocation fails, ever think about that? Second, the allocation is successfull, but you had to allocate a large chunk of memory and initialize it. As always it depends on the object but usually the initialization isn't cheap but for sake of argument lets say it is. So now you have a temporary object. Well after the current line is finished executing you have to perform a copy and a delete which I guarantee is not going to be as fast as simply incrementing with the pre op.
In conclusion the pre op should be the default mechanism, unless you truly need the data pre-modified.
Picture this...for whatever reason your user defined type has dynamic memory associated with it. First of all, allocating memory in a constructor is dangerous, what happens if the allocation fails, ever think about that? Second, the allocation is successfull, but you had to allocate a large chunk of memory and initialize it. As always it depends on the object but usually the initialization isn't cheap but for sake of argument lets say it is. So now you have a temporary object. Well after the current line is finished executing you have to perform a copy and a delete which I guarantee is not going to be as fast as simply incrementing with the pre op.
In conclusion the pre op should be the default mechanism, unless you truly need the data pre-modified.
The previous posters are of course correct. To reiterate...
preincrement (++i) should be preferred, unless you need to use the original value in the statement containing the increment expression, before incrementing it.
It does not always make a diference in speed, particularly when using built-in types, but it does often make a slight difference in speed in other cases.
STL is one place where you really should preincrement whenever possible, for efficiency reasons.
The reasons people sometimes don't do this is that they do not know about the preincrement operator, or do not like the syntax as much.
so a simple for loop should preferably be written like this:
preincrement (++i) should be preferred, unless you need to use the original value in the statement containing the increment expression, before incrementing it.
It does not always make a diference in speed, particularly when using built-in types, but it does often make a slight difference in speed in other cases.
STL is one place where you really should preincrement whenever possible, for efficiency reasons.
The reasons people sometimes don't do this is that they do not know about the preincrement operator, or do not like the syntax as much.
so a simple for loop should preferably be written like this:
for (int i=0; i<100; ++i)foobar(a);++a;foobar(a++);b++;++b;Quote:
STL is one place where you really should preincrement whenever possible, for efficiency reasons.
Or use an algorithm, for even greater efficiency...
Jim.
Or you could just not use either operator. Any operator that constantly generates long threads about it's proper use, is error prone, and is suseptible to undefined behavior just isn't worth the effort. They're also a maintainence nightmare.
In modern compilers you won't realistically get any significant perf increase over sane operators so there's no real reason to use them at all.
In modern compilers you won't realistically get any significant perf increase over sane operators so there's no real reason to use them at all.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
