This question already has answers here:
Closed 12 years ago.
The community reviewed whether to reopen this question last month and left it closed:
Original close reason(s) were not resolved
Possible Duplicate:
Is there a performance difference between i++ and ++i in C++?
Is there a reason some programmers write ++i in a normal for loop instead of writing i++?
++i is slightly more efficient due to its semantics:
++i; // Fetch i, increment it, and return it
i++; // Fetch i, copy it, increment i, return copy
For int-like indices, the efficiency gain is minimal (if any). For iterators and other heavier-weight objects, avoiding that copy can be a real win (particularly if the loop body doesn't contain much work).
As an example, consider the following loop using a theoretical BigInteger class providing arbitrary precision integers (and thus some sort of vector-like internals):
std::vector<BigInteger> vec;
for (BigInteger i = 0; i < 99999999L; i++) {
vec.push_back(i);
}
That i++ operation includes copy construction (i.e. operator new, digit-by-digit copy) and destruction (operator delete) for a loop that won't do anything more than essentially make one more copy of the index object. Essentially you've doubled the work to be done (and increased memory fragmentation most likely) by simply using the postfix increment where prefix would have been sufficient.
For integers, there is no difference between pre- and post-increment.
If i is an object of a non-trivial class, then ++i is generally preferred, because the object is modified and then evaluated, whereas i++ modifies after evaluation, so requires a copy to be made.
++i is a pre-increment; i++ is post-increment.
The downside of post-increment is that it generates an extra value; it returns a copy of the old value while modifying i. Thus, you should avoid it when possible.
With integers, it's preference.
If the loop variable is a class/object, it can make a difference (only profiling can tell you if it's a significant difference), because the post-increment version requires that you create a copy of that object that gets discarded.
If creating that copy is an expensive operation, you're paying that expense once for every time you go through the loop, for no reason at all.
If you get into the habit of always using ++i in for loops, you don't need to stop and think about whether what you're doing in this particular situation makes sense. You just always are.
There is a reason for this: performance. i++ generates a copy, and that's a waste if you immediately discard it. Granted, the compiler can optimize away this copy if i is a primitive, but it can't if it isn't. See this question.
No compiler worth its weight in salt will run differently between
for(int i=0; i<10; i++)
and
for(int i=0;i<10;++i)
++i and i++ have the same cost. The only thing that differs is that the return value of ++i is i+1 whereas the return value of i++ is i.
So for those prefering ++i, there's probably no valid justification, just personal preference.
EDIT: This is wrong for classes, as said in about every other post. i++ will generate a copy if i is a class.
As others have already noted, pre-increment is usually faster than post-increment for user-defined types. To understand why this is so, look at the typical code pattern to implement both operators:
Foo& operator++()
{
some_member.increase();
return *this;
}
Foo operator++(int dummy_parameter_indicating_postfix)
{
Foo copy(*this);
++(*this);
return copy;
}
As you can see, the prefix version simply modifies the object and returns it by reference.
The postfix version, on the other hand, must make a copy before the actual increment is performed, and then that copy is copied back to the caller by value. It is obvious from the source code that the postfix version must do more work, because it includes a call to the prefix version: ++(*this);
For built-in types, it does not make any difference as long as you discard the value, i.e. as long as you do not embed ++i or i++ in a larger expression such as a = ++i or b = i++.
when you use postfix it instantiates on more object in memory. Some people say that it is better to use suffix operator in for loop
Personal preference.
Usually. Sometimes it matters but, not to seem like a jerk here, but if you have to ask, it probably doesn't.
Related
This question already has answers here:
Is there a performance difference between i++ and ++i in C++?
(20 answers)
Closed 6 years ago.
I usually think that preincrement is more efficient than postincrement in C++. But when I read the book Game Engine Architecture(2nd ed.) recently, there is a section says that postincrement is prefered than preincrement in for loop. Because, as I quote, "preincrement introduces a data dependency into your code -- the CPU must wait for the increment operation to be completed before its value can be used in the expression." Is this true? (It is really subverted my idea about this problem.)
Here is the quote from the section in case you are interested:
5.3.2.1 Preincrement versus Postincrement
Notice in the above example that we are using C++’s postincrement operator,
p++, rather than the preincrement operator, ++p. This is a subtle but sometimes important optimization. The preincrement operator increments the contents of the variable before its (now modified) value is used in the expression. The postincrement operator increments the contents of the variable after it has been used. This means that writing ++p introduces a data dependency into your code -- the CPU must wait for the increment operation to be completed before its value can be used in the expression. On a deeply pipelined CPU, this introduces a stall. On the other hand, with p++ there is no data dependency. The value of the variable can be used immediately, and the increment operation can happen later or in parallel with its use. Either way, no stall is introduced into the pipeline.
Of course, within the “update” expression of a for loop (for(init_expr;
test_expr; update_expr) { ... }), there should be no difference between
pre- and postincrement. This is because any good compiler will recognize that
the value of the variable isn’t used in update_expr. But in cases where the
value is used, postincrement is superior because it doesn’t introduce a stall
in the CPU’s pipeline. Therefore, it’s good to get in the habit of always using
postincrement, unless you absolutely need the semantics of preincrement.
Edit: Add "the above example".
void processArray(int container[], int numElements)
{
int* pBegin = &container[0];
int* pEnd = &container[numElements];
for (int* p = pBegin; p != pEnd; p++)
{
int element = *p;
// process element...
}
}
void processList(std::list<int>& container)
{
std::list<int>::iterator pBegin = container.begin();
std::list<int>::iterator pEnd = container.end();
std::list<inf>::iterator p;
for (p = pBegin; p != pEnd; p++)
{
int element = *p;
// process element...
}
}
pre-increment introduces a data dependency into your code -- the CPU must wait for the increment operation to be completed before its value can be used in the expression."
Is this true?
It is mostly true - although perhaps overly strict. Pre increment doesn't necessarily introduce a data dependency - but it can.
A trivial example for exposition:
a = b++ * 2;
Here, the increment can be executed in parallel with the multiplication. The operands of both the increment and the multiplication are immediately available and do not depend on the result of either operation.
Another example:
a = ++b * 2;
Here, the multiplication must be executed after the increment, because one of the operands of the multiplication depends on the result of the increment.
Of course, these statements do slightly different things, so the compiler might not always be able to transform the program from one form to the other while keeping the semantics the same - which is why using the post-increment might make a slight difference in performance.
A practical example, using a loop:
for(int i= 0; arr[i++];)
count++;
for(int i=-1; arr[++i];) // more typically: (int i=0; arr[i]; ++i;)
count++;
One might think that the latter is necessarily faster if they reason that "post-increment makes a copy" - which would have been very true in the case of non-fundamental types. However, due to the data dependency (and because int is a fundamental type with no overload function for increment operators), the former can theoretically be more efficient. Whether it actually is depends on the CPU architecture, and the ability of the optimizer.
For what it's worth - in a trivial program, on x86 arch, using g++ compiler with optimization enabled, the above loops had identical assembly output, so they are perfectly equivalent in that case.
Rules of thumb:
If the counter is a fundamental type and the result of increment is not used, then it makes no difference whether you use post/pre-increment.
If the counter is not a fundamental type and the result of the increment is not used and optimizations are disabled, then pre-increment may be more efficient. With optimizations enabled, there is usually no difference.
If the counter is a fundamental type and the result of increment is used, then post-increment can theoretically be marginally more efficient - in some CPU architecture - in some context - using some compiler.
If the counter is not a fundamental type and the result of the increment is used, then pre-increment is typically faster than post-increment. Also, see R Sahu's answer regarding this case.
One point of data from my experience.
Changing a post-increment to a pre-increment of a std::map::iterator in for loops resulted in noticeable savings in a core algorithm at my work.
In general, when icrementing an iterator that is a class, i.e. it is not a pointer, you should notice savings when using the pre-increment operator. The reason for it is that the pre-increment operator function changes the object in place while the post increment operator function usually involves creation of a temporary object.
A pre-increment operator is usually implemented as:
typename& typename::operator++()
{
// Change state
...
// Return the object
return *this;
}
while a post-increment operator is usually implemented as:
typename typename::operator++(int)
{
// Create a temporary object that is a copy of the current object.
typename temp(*this):
// Change state of the current object
...
// Return the temporary object.
return temp;
}
This question already has answers here:
Is there a performance difference between i++ and ++i in C++?
(20 answers)
Closed 6 years ago.
I usually think that preincrement is more efficient than postincrement in C++. But when I read the book Game Engine Architecture(2nd ed.) recently, there is a section says that postincrement is prefered than preincrement in for loop. Because, as I quote, "preincrement introduces a data dependency into your code -- the CPU must wait for the increment operation to be completed before its value can be used in the expression." Is this true? (It is really subverted my idea about this problem.)
Here is the quote from the section in case you are interested:
5.3.2.1 Preincrement versus Postincrement
Notice in the above example that we are using C++’s postincrement operator,
p++, rather than the preincrement operator, ++p. This is a subtle but sometimes important optimization. The preincrement operator increments the contents of the variable before its (now modified) value is used in the expression. The postincrement operator increments the contents of the variable after it has been used. This means that writing ++p introduces a data dependency into your code -- the CPU must wait for the increment operation to be completed before its value can be used in the expression. On a deeply pipelined CPU, this introduces a stall. On the other hand, with p++ there is no data dependency. The value of the variable can be used immediately, and the increment operation can happen later or in parallel with its use. Either way, no stall is introduced into the pipeline.
Of course, within the “update” expression of a for loop (for(init_expr;
test_expr; update_expr) { ... }), there should be no difference between
pre- and postincrement. This is because any good compiler will recognize that
the value of the variable isn’t used in update_expr. But in cases where the
value is used, postincrement is superior because it doesn’t introduce a stall
in the CPU’s pipeline. Therefore, it’s good to get in the habit of always using
postincrement, unless you absolutely need the semantics of preincrement.
Edit: Add "the above example".
void processArray(int container[], int numElements)
{
int* pBegin = &container[0];
int* pEnd = &container[numElements];
for (int* p = pBegin; p != pEnd; p++)
{
int element = *p;
// process element...
}
}
void processList(std::list<int>& container)
{
std::list<int>::iterator pBegin = container.begin();
std::list<int>::iterator pEnd = container.end();
std::list<inf>::iterator p;
for (p = pBegin; p != pEnd; p++)
{
int element = *p;
// process element...
}
}
pre-increment introduces a data dependency into your code -- the CPU must wait for the increment operation to be completed before its value can be used in the expression."
Is this true?
It is mostly true - although perhaps overly strict. Pre increment doesn't necessarily introduce a data dependency - but it can.
A trivial example for exposition:
a = b++ * 2;
Here, the increment can be executed in parallel with the multiplication. The operands of both the increment and the multiplication are immediately available and do not depend on the result of either operation.
Another example:
a = ++b * 2;
Here, the multiplication must be executed after the increment, because one of the operands of the multiplication depends on the result of the increment.
Of course, these statements do slightly different things, so the compiler might not always be able to transform the program from one form to the other while keeping the semantics the same - which is why using the post-increment might make a slight difference in performance.
A practical example, using a loop:
for(int i= 0; arr[i++];)
count++;
for(int i=-1; arr[++i];) // more typically: (int i=0; arr[i]; ++i;)
count++;
One might think that the latter is necessarily faster if they reason that "post-increment makes a copy" - which would have been very true in the case of non-fundamental types. However, due to the data dependency (and because int is a fundamental type with no overload function for increment operators), the former can theoretically be more efficient. Whether it actually is depends on the CPU architecture, and the ability of the optimizer.
For what it's worth - in a trivial program, on x86 arch, using g++ compiler with optimization enabled, the above loops had identical assembly output, so they are perfectly equivalent in that case.
Rules of thumb:
If the counter is a fundamental type and the result of increment is not used, then it makes no difference whether you use post/pre-increment.
If the counter is not a fundamental type and the result of the increment is not used and optimizations are disabled, then pre-increment may be more efficient. With optimizations enabled, there is usually no difference.
If the counter is a fundamental type and the result of increment is used, then post-increment can theoretically be marginally more efficient - in some CPU architecture - in some context - using some compiler.
If the counter is not a fundamental type and the result of the increment is used, then pre-increment is typically faster than post-increment. Also, see R Sahu's answer regarding this case.
One point of data from my experience.
Changing a post-increment to a pre-increment of a std::map::iterator in for loops resulted in noticeable savings in a core algorithm at my work.
In general, when icrementing an iterator that is a class, i.e. it is not a pointer, you should notice savings when using the pre-increment operator. The reason for it is that the pre-increment operator function changes the object in place while the post increment operator function usually involves creation of a temporary object.
A pre-increment operator is usually implemented as:
typename& typename::operator++()
{
// Change state
...
// Return the object
return *this;
}
while a post-increment operator is usually implemented as:
typename typename::operator++(int)
{
// Create a temporary object that is a copy of the current object.
typename temp(*this):
// Change state of the current object
...
// Return the temporary object.
return temp;
}
This question already has answers here:
Why use ++i instead of i++ in cases where the value is not used anywhere else in the statement?
(7 answers)
Technical reasons behind formatting when incrementing by 1 in a 'for' loop?
(31 answers)
Closed 9 years ago.
I have a question about writing loops. I always begin with
(int i=0; i<10; i++)
But I see many experts begin with
(int i=0; i<10; ++i)
Is there there any real difference, or they are same?
Of course, I know the difference between pre-increment and post-increment. I mean which one I should use when writing the loop? or it depends.
Thanks!
There is no difference among the two. Pre increment and post increment are the only
difference.
The difference between i++ and ++i is the value of the expression.
The value i++ is the value of i before the increment. The value of ++i is the value of i after the increment.
However in your loop it does not make any difference.
int i = 0;
00000088 xor edx,edx
0000008a mov dword ptr [ebp-40h],edx
i++;
0000008d inc dword ptr [ebp-40h]
++i;
00000090 inc dword ptr [ebp-40h]
As you can see it does not make any difference in performance but in certain situations you might want to increment a number right after a sequence point or before it.
In C++ ++i is an l-value, but i++ is not.
In C++ there is a difference. While the prefix operator will return a reference to the value, the postfix operator will return a copy and therefore is slower than the prefix operator.
The main difference between pre- and post-incrementing lies in the return value.
Post-incrementing returns the value which has been present before the variable has been increased, essentially creating a copy of the old value. Pre-incrementing returns a reference to the new value, thereby avoiding the creation of a temporary variable.
Generally speaking it does not make a difference and is mostly a matter of taste, but in certain cases where memory is short the pre-increment option might be more useful. I also read that the post-increment version is supposed to be slower (as it creates a new temporary variable) but I have not found any conclusive proof of that
Preincrement is generally preferred because while it makes no difference for primitive types it may be faster for iterators as preincrement doesn't have to return a copy of its old value.
Since preincrement is sometimes faster (with non primitive types like iterators) it is a good habit to get into even where it makes no performance difference which is why many people recommend it. This is item 28 in C++ Coding Standards for example.
I'm trying to learn some c++, to start off I created some methods to handle outputing to and reading from a console.
I'm having 2 major problems, marked in the code, manipulating/accessing values within a std::vector of strings passed in by reference.
The method below takes in a question (std string) to ask the user and a vector std strings that contain responses from the user deemed acceptable. I also wanted, in the interest of learning, to access a string within the vector and change its value.
std::string My_Namespace::My_Class::ask(std::string question, std::vector<std::string> *validInputs){
bool val = false;
std::string response;
while(!val){
//Ask and get a response
response = ask(question);
//Iterate through the acceptable responses looking for a match
for(unsigned int i = 0; i < validInputs->size(); i++){
if(response == validInputs->at(i)){
////1) Above condition always returns true/////
val = true;
break;
}
}
}
//////////2) does not print anything//////////
println(validInputs->at(0)); //note the println method is just cout << param << "\n" << std::endl
//Really I want to manipulate its value (not the pointer the actual value)
//So I'd want something analogous to validInputs.set(index, newVal); from java
///////////////////////////////////////////
}
A few additional questions:
3) I'm using .at(index) on the the vector to get the value but I've read that [] should be used instead, however I'm not sure what that should look like (validInputs[i] doesn't compile).
4) I assume that since a deep copy is unnecessary its good practice to pass in a pointer to the vector as above, can someone verify that?
5) I've heard that ++i is better practice than i++ in loops, is that true? why?
3) There should not be a significant difference using at and operator[] in this case. Note that you have a pointer-to-vector, not a vector (nor reference-to-vector) so you will have to use either (*validInputs)[i] or validInputs->operator[](i) to use the operator overload. Using validInputs->at(i) is fine if you don't want to use either of these other approaches. (The at method will throw an exception if the argument is out of the array bounds, while the operator[] method has undefined behavior when the argument is out of the array bounds. Since operator[] skips the bounds check, it is faster if you know for a fact that i is within the vector's bounds. If you are not sure, use at and be prepared to catch an exception.)
4) A pointer is good, but a reference would be better. And if you're not modifying the vector in the method, a reference-to-const-vector would be best (std::vector<std::string> const &). This ensures that you cannot be passed a null pointer (references cannot be null), while also ensuring that you don't accidentally modify the vector.
5) It usually is. i++ is post-increment, which means that the original value must be copied, then i is incremented and the copy of the original value is returned. ++i increments i and then returns i, so it is usually faster, especially when dealing with complex iterators. With an unsigned int the compiler should be smart enough to realize that a pre-increment will be fine, but it's good to get into the practice of using ++i if you don't need the original, unincremented value of i.
I'd use a reference-to-const, and std::find. Note that I also take the string by reference (it gets deep copied otherwise) :
std::string My_Class::
ask (const std::string& question, const std::vector<std::string>& validInputs)
{
for (;;) {
auto response = ask (question);
auto i = std::find (validInputs.begin (), validInputs.end (), response);
if (i != validInputs.end ()) {
std::cout << *i << '\n'; // Prints the value found
return *i;
}
}
}
Read about iterators if you don't understand the code. Of course, feel free to ask other questions if you need.
I'm not going to address points 1 and 2 since we don't know what you are doing and we don't even see the code for ask and println.
I'm using .at(index) on the the vector to get the value but I've read that [] should be used instead, however I'm not sure what that should look like (validInputs[i] doesn't compile).
Subscript access and at member function are different things. They give you the very same thing, a reference to the indexed element, but they behave differently if you pass an out-of bounds index: at will throw an exception while [] will invoke undefined behavior (as builtin arrays do). Using [] on a pointer is somewhat ugly, (*validInputs)[i], but you really should avoid pointers when possible.
I assume that since a deep copy is unnecessary its good practice to pass in a pointer to the vector as above, can someone verify that?
A deep copy is unnecessary, but so is a pointer. You want a reference instead, and a const one since I presume you shouldn't be modifying those:
ask(std::string const& question, std::vector<std::string> const& validInputs)
I've heard that ++i is better practice than i++ in loops, is that true? why?
Its true in the general case. The two operations are different, ++i increments i and returns the new value while i++ increments i but returns the value before the incrementation, which requires a temporary to be hold and returned. For ints this hardly matters, but for potentially fat iterators preincrement is more efficient and a better choice if you don't need or care for its return value.
To answer questions 1 and 2, we'll probably need more information, like: How did you initialize validInputs? What's the source of ask?
3) First dereference the pointer, then index the vector:
(*validInputs)[i]
4) References are considered better style. Especially instead of pointers which never are NULL.
5) For integers, it doesn't matter (unless you evaluate the result of the expression). For other objects, with overloaded ++ operators (iterators, for example) it may be better to use ++i. But in practice, for inline definitions of the ++ operator, it will probably be optimized to the same code.
I'm well aware that in C++
int someValue = i++;
array[i++] = otherValue;
has different effect compared to
int someValue = ++i;
array[++i] = otherValue;
but every once in a while I see statements with prefix increment in for-loops or just by their own:
for( int i = 0; i < count; ++i ) {
//do stuff
}
or
for( int i = 0; i < count; ) {
//do some stuff;
if( condition ) {
++i;
} else {
i += 4;
}
}
In the latter two cases the ++i looks like an attempt to produce smarty-looking code. Am I overseeing something? Is there a reason to use ++i instead of i++ in the latter two cases?
Look at possible implementations of the two operators in own code:
// Pre-increment
T*& operator ++() {
// Perform increment operation.
return *this;
}
// Post-increment
T operator ++(int) {
T copy = *this;
++*this;
return copy;
}
The postfix operator invokes the prefix operator to perform its own operation: by design and in principle the prefix version will always be faster than the postfix version, although the compiler can optimize this in many cases (and especially for builtin types).
The preference for the prefix operator is therefore natural; it’s the other that needs explanation: why are so many people intrigued by the use of the prefix operator in situations where it doesn’t matter – yet nobody is ever astonished by the use of the postfix operator.
If we ignore force of habit, '++i' is a simpler operation conceptually: It simply adds one to the value of i, and then uses it.
i++ on the other hand, is "take the original value of i, store it as a temporary, add one to i, and then return the temporary". It requires us to keep the old value around even after i has been updated.
And as Konrad Rudolph showed, there can be performance costs to using i++ with user-defined types.
So the question is, why not always just default to ++i?
If you have no reason to use `i++´, why do it? Why would you default to the operation which is more complicated to reason about, and may be slower to execute?
As you noted - it does not matter to the result.
There is a performance consideration for non-primitive types.
Also semantically using pre-increment is usually clearer in showing the intention of a test when the return value is used, so its better to use it habitually than post-increment to avoid accidentally testing the old value.
There is one reason, and it has to do with overloaded operators. In an overloaded postincrement function, the function must remember the previous value of the object, increment it, and then return the previous value. In a preincrement function, the function can simply increment the object and then return a reference to itself (its new value).
In the case of an integer, the above probably won't apply because the compiler knows the context in which the increment is being done, and will generate appropriate increment code in either case.
Yes, for performance reasons. In case of post increment a copy of the variable i needs to be made before incrementing so that the old value can be returned (eventhough you are not using the return value). In case of pre-increment this copy is not required.
There is little reason to favour pre-increment over post-increment when you are talking about natural types like integers. The compiler is typically able to generate the same code in both cases anyway, assuming you don't use the return value. This is not true for more complex types, such as iterators.
The C++ FAQ Lite has a nice discussion of i++ vs. ++i here:
[13.15] Which is more efficient: i++ or ++i?
In particular, with respect to which form to use within a for loop, the FAQ expresses a preference for ++i. Here's the text:
So if you're writing i++ as a statement rather than as part of a
larger expression, why not just write ++i instead? You never lose
anything, and you sometimes gain something. Old line C programmers are
used to writing i++ instead of ++i. E.g., they'll say, for (i = 0; i <10; i++)
.... Since this uses i++ as a statement, not as a part of a
larger expression, then you might want to use ++i instead. For
symmetry, I personally advocate that style even when it doesn't
improve speed, e.g., for intrinsic types and for class types with
postfix operators that return void.