Printable View
[Andreas]: The following question is asked in regard to the following FAQ:
You mention that for regular variables (like int) there is no performance gain. Is this statement true for C++ but not for C? I've come across several people who do ++i all the time rather than i++ (in C) claiming efficiency gains.
[ Split thread ]
normally it's a question of whether your compiler is able to "take a look" inside operator's implementation and optimise away a temporary variable if it's really not needed (not used by the caller code). for native compiler types it's possible and, more to say, with a clever compiler it's even possible with a user defined type under some circumstances.Quote:
Originally Posted by C++ Newbie
e.g. when class's operator++ (int) is defined with "inline" specificator.
the recent c compilers do this optimization (at least, I have checked it out with gcc 3.3.4). what's about using ++i instead of i++? I guess it becomes a matter of habbit with time. e.g. if I know that I donot need an old value of the variable, I just don't use i++ even for for-loops.
Personally, I think ++i reads better: "increment i", rather than i++ - "i increment".
Since C does not allow to overload operator ++, you can only use this operator on builtins types, so the performances of prefix and postfix versions are basically identical (at least if the return value is not used, the assembly code generated will be the same).Quote:
Originally Posted by C++ Newbie
But, it is better to use ++i
- It is a good habit to use ++i, so you don't have to think about what version you use, and you will not accidentally use i++ where you should have used ++i
- It is easier for the programmer's mind, to don't matter which operator to use.
- If a day, you want to replace your C-style pointers to array by iterators of a STL container, you will need less code modification for optimal performances.
Note that for an easy conversion, it is generally good to typedef pointers that you use much, so you can replace them by iterators by changing a single line of code.- As Graham said, ++i can be literally read "increment i" which is maybe more intuitive than i++. But for an advanced programmer i don't think it makes any difference.
I don't understand why books i read used i++ everywhere, so, during a long time, i had the bad habit to use i++.
But i think that it is far better to get the good habits (especially if they are easy to take) from the begining of C++ learning.
I also use i++ because of habbit over the past 20 or so years and never use ++i. Also use it on c++ iterators in for loops and for most other pointers. None of my programs are time-critical so speed difference of a couple clock ticks is unimportant.
++i as know as PreIncrement
and i++ as post increment
if you consider then in a loop
like for or something else
there is no difference between ++ior i++
but as we know ++i first increment the value by one then print
but i++ first print the value then increment.
means i++ uses more cpu cycle.
so it's upto you which one you want to use .most people like to use i++.becuase from the start onwards they think or they start write like this only i++ means increment the value of i by 1.
they think ++i at the time when they have to use preincrement operator
so better to use ++i.to minimize your cpu cycle.and improve your speed
Print? Print what? Did you mean evaluate?Quote:
Originally Posted by humptydumpty
Personally, I think the opposite. ;)Quote:
Originally Posted by Graham
I might agree with that in an application that does that millions of times a second -- but in other applications it doesn't make a hoot which you use. Whether you use ++i or i++ is merly a personal decision, beyond that it is a moot question. Who the he11 cares whether i++ takes 1 or 2 clock ticks more than ++i??? Your time and efforts to optimize a program are much better spent elsewhere. [edit] you might care if you are compiling for a very sloooooooooow computer[/edit]Quote:
Originally Posted by humptydumpty
I don't agree.Quote:
Originally Posted by stober
- It is better that all programmers use the same convention.
So why not use preincrement, since it is a little better?- Generally preincrement and postincrement have the same performance, but for iterators as deque::iterator, the difference not negligible.
For example, i found that for a copy from deque to deque, using postincrement is more than two times slower than preincrement, with my computer, and my STL.
For complex algorithms this may be not an issue, if much processing is done between to calls to the increment iterator.
But, since STL is everywhere nowadays, it is probable that for some actual programs, and some future programs, the CPU time executing various increment operators on various iterators of various containers, may use 50% of CPU cycles.
In fact when using deque, generally dereferencing is fact, but incrementation is slow, so the incrementation may take 75% CPU cycles on some algorithms using deque on a simple data structure (deque<char> for example).
If you replace only one postincrement by one preincrement in your whole code, you will probably not notify the difference, but if you replace them all, it can make a big difference.- Even if the two things are nearly identical, why not using the best one?
Don't say that it is easier to write "i++" than "++i", for the programmer learning C++, there is no difference choosing one or the other, so it is better to get the good habit from the start.
Everyone is entitled to his/her own opinion :)Quote:
Originally Posted by SuperKoko
That will surly be a very cold day in he11 :D There are as many ways to write a program as there are programmers to write them. But company coding standards (and I hope most software houses have them) should standardize most of that.Quote:
Originally Posted by SuperKoko
I'll accpet your opinion and experience on that. It never occurred to me to use pre-increment on iterators because all the text I read used post-increment. I assumed (maybe wrongly) that iterators were just another kind of pointer, and pre-post increment debate would apply to them as it does to integers.Quote:
Originally Posted by SuperKoko
BTW: Thanks for showing me how to use the [ list ] HTML tags -- I've been woundering how those bullets were made. :)
After this long discussion on the preferences based on performance, I would add up a thing.
This depends on the way your need for the incrementation is. I mean if you need the incremented value of a variable in the statement where you are doing you might want to use ++i and if you want the older value of the variable in the statement where you use ++ and want that it should have an incremented value later use i++. Basically what I am talking about is related to the actual meaning of post and pre increment. Performance reasons are always there but you should never neglect the actual objective of your code.
I think some sample code use showing the difference between "preincremented" and "postincremented" will help here:
int i=10;
cout<<i++<<endl;
cout<<i<<endl;
int d=10
cout<<++d<<endl;
cout<<d<<endl;
output:
10
11
11
11
I use ++i everytime that I don't need to increment after using the variable. It just seems better.
I prefer to use ++i but I did come from a C background originally and i++ was far more popular (perhaps why the language is called C++ and not ++C). Perhaps because i++ is shorthand for i+=1 (at least it appears to be) where the operation on i is on the right-hand side. You cannot do 1+=i (1 is not an l-value) or even 1=+i (same error).
Hehe, even if 'i+=1' looks like a shortland of 'i++', it is equivalent to '++i' and it is different of 'i++'. ;)Quote:
Originally Posted by NMTop40
I hope that no C programmer wrote buggy program because of that confusion.
:D
++C, it looks like a pretty language, maybe in the future...
It's called C++ because it's an incremental improvement over C, but most programmers still use the original value...
I think that's an excellent way to put it, Graham. :)Quote:
Originally Posted by Graham
I'm sorry if I just missed it, but I didn't see the primary reason for avoiding a post-increment (x++) in C++; while for simple, intrinsic datatypes, there is usually no difference, if you are using an increment on an object, the post-increment calls a copy constructor to build a new object, where the pre-increment doesn't.
so ++i is faster for objects so its better to get used to using ++i than using i++
also having a mix of i++ and ++obj looks bad
First of all, the post increment and pre increment operators (basically ++) is not by default defined with classes. So you wont be able to do that for objects as you mentioned. Secondly, it depends how they are implemented - they might as well be acting upon the intrinsic datatypes in turn, as defined by the implementer. So, who knows without having implementation in hand? So your statement is kind of not complete in my opinion.Quote:
Originally Posted by rdrast
The point is that pre-increment will never be slower than post-increment and may be faster.
In C we donot have operator overloading concept. so both r same. Now in C++ it depends on how u implement. As per general implementation if my class name is ClassEx and if I want to overload the post/pre increment operators We do as
Pre increment (++i)
================
ClassEx& operator ++()
{
++(*this);
......
return *this;
}
Post Increment (i++)
================
ClassEx operator(int)
{
ClassEx clNew = this;
++(*this);
return clNew;
}
So Now for preincrement we return a reference....for post increment we return an object that is created newly.....
So ++i is faster than i++..........atleast you will not loose any thing in using ++i..........u will gain something....
Thanks,
Anand.
ClassEx clNew = this; won't work, not unless you have defined operator= like this:Quote:
Originally Posted by anand_chavali
which is unlikely. In any case in your implementation neither is faster since your pre-increment recurses ad-infinitum, and your post-incrementer calls it thus also recurses ad-infinitum. Well logically they take the same time as infinity plus a bit is not greater than infinity, but either way you'll run out of stack and I don't know which one will run you out of stack quicker.Code:class ClassEx
{
public:
ClassEx& operator=( const ClassEx * );
}
Now:
Anyway, operator++(int) makes 2 copies. The second one will probably be optimised away by the compiler but it's unlikely the first one will be even if you don't access the return value.Code:class ClassEx
{
public:
ClassEx& operator++()
{
// perform the increment as appropriate
return *this;
}
ClassEx operator++(int)
{
ClassEx temp( *this ); // not = this
operator++(); // equivalent to ++(*this)
return temp;
}
};
As a point of interest though, when you DO want the original value and then increment, is it still better to use pre-increment (thus 2 statements). eg
as an implementation of copy
orCode:template < typename FwdIt, typename OutIt >
void copy( FwdIt begin, FwdIt end, OutIt dest )
{
while ( begin != end )
{
*dest++ = *begin++;
}
}
The second one appears to use more lines of code but given the implementation of operator++(int) perhaps it is illusionary? (If the iterators really are pointers it probably makes no difference but what if they are not pointers?)Code:template < typename FwdIt, typename OutIt >
void copy( FwdIt begin, FwdIt end, OutIt dest )
{
while ( begin != end )
{
*dest = *begin;
++dest;
++begin;
}
}