Incrementing in C++ - When to use x++ or ++x? - c++

I'm currently learning C++ and I've learned about the incrementation a while ago.
I know that you can use "++x" to make the incrementation before and "x++" to do it after.
Still, I really don't know when to use either of the two... I've never really used "++x" and things always worked fine so far - so, when should I use it?
Example: In a for loop, when is it preferable to use "++x"?
Also, could someone explain exactly how the different incrementations (or decrementations) work? I would really appreciate it.

It's not a question of preference, but of logic.
x++ increments the value of variable x after processing the current statement.
++x increments the value of variable x before processing the current statement.
So just decide on the logic you write.
x += ++i will increment i and add i+1 to x.
x += i++ will add i to x, then increment i.

Scott Meyers tells you to prefer prefix except on those occasions where logic would dictate that postfix is appropriate.
"More Effective C++" item #6 - that's sufficient authority for me.
For those who don't own the book, here are the pertinent quotes. From page 32:
From your days as a C programmer, you may recall that the prefix form of the increment operator is sometimes called "increment and fetch", while the postfix form is often known as "fetch and increment." The two phrases are important to remember, because they all but act as formal specifications...
And on page 34:
If you're the kind who worries about efficiency, you probably broke into a sweat when you first saw the postfix increment function. That function has to create a temporary object for its return value and the implementation above also creates an explicit temporary object that has to be constructed and destructed. The prefix increment function has no such temporaries...

From cppreference when incrementing iterators:
You should prefer pre-increment
operator (++iter) to post-increment
operator (iter++) if you are not going
to use the old value. Post-increment
is generally implemented as follows:
Iter operator++(int) {
Iter tmp(*this); // store the old value in a temporary object
++*this; // call pre-increment
return tmp; // return the old value }
Obviously, it's less efficient than
pre-increment.
Pre-increment does not generate the temporary object. This can make a significant difference if your object is expensive to create.

I just want to notice that the geneated code is offen the same if you use pre/post incrementation where the semantic (of pre/post) doesn't matter.
example:
pre.cpp:
#include <iostream>
int main()
{
int i = 13;
i++;
for (; i < 42; i++)
{
std::cout << i << std::endl;
}
}
post.cpp:
#include <iostream>
int main()
{
int i = 13;
++i;
for (; i < 42; ++i)
{
std::cout << i << std::endl;
}
}
_
$> g++ -S pre.cpp
$> g++ -S post.cpp
$> diff pre.s post.s
1c1
< .file "pre.cpp"
---
> .file "post.cpp"

The most important thing to keep in mind, imo, is that x++ needs to return the value before the increment actually took place -- therefore, it has to make a temporary copy of the object (pre increment). This is less effecient than ++x, which is incremented in-place and returned.
Another thing worth mentioning, though, is that most compilers will be able to optimize such unnecessary things away when possible, for instance both options will lead to same code here:
for (int i(0);i<10;++i)
for (int i(0);i<10;i++)

I agree with #BeowulfOF, though for clarity I would always advocate splitting the statements so that the logic is absolutely clear, i.e.:
i++;
x += i;
or
x += i;
i++;
So my answer is if you write clear code then this should rarely matter (and if it matters then your code is probably not clear enough).

If count{5};
If you use ++count it will be process beforethe statement
total = --count +6;
Total will be equal to 10
If you use count++ it will be process after the statement
total = count-- +6;
Total will be equal to 11

Just wanted to re-emphasize that ++x is expected to be faster than x++, (especially if x is an object of some arbitrary type), so unless required for logical reasons, ++x should be used.

Postfix form of ++,-- operator follows the rule use-then-change ,
Prefix form (++x,--x) follows the rule change-then-use.
Example 1:
When multiple values are cascaded with << using cout then calculations(if any) take place from right-to-left but printing takes place from left-to-right e.g., (if val if initially 10)
cout<< ++val<<" "<< val++<<" "<< val;
will result into
12 10 10
Example 2:
In Turbo C++, if multiple occurrences of ++ or (in any form) are found in an expression, then firstly all prefix forms are computed then expression is evaluated and finally postfix forms are computed e.g.,
int a=10,b;
b=a++ + ++a + ++a + a;
cout<<b<<a<<endl;
It's output in Turbo C++ will be
48 13
Whereas it's output in modern day compiler will be (because they follow the rules strictly)
45 13
Note: Multiple use of increment/decrement operators on same variable
in one expression is not recommended. The handling/results of such
expressions vary from compiler to compiler.

You explained the difference correctly. It just depends on if you want x to increment before every run through a loop, or after that. It depends on your program logic, what is appropriate.
An important difference when dealing with STL-Iterators (which also implement these operators) is, that it++ creates a copy of the object the iterator points to, then increments, and then returns the copy. ++it on the other hand does the increment first and then returns a reference to the object the iterator now points to. This is mostly just relevant when every bit of performance counts or when you implement your own STL-iterator.
Edit: fixed the mixup of prefix and suffix notation

You asked for an example:
This (order is a std::vector) will crash for i == order.size()-1 on the order[i].size() access:
while(i++ < order.size() && order[i].size() > currLvl);
This will not crash at order[i].size(), as i will be incremented, checked and the loop will be exited:
while(++i < order.size() && order[i].size() > currLvl);

Understanding the language syntax is important when considering clarity of code. Consider copying a character string, for example with post-increment:
char a[256] = "Hello world!";
char b[256];
int i = 0;
do {
b[i] = a[i];
} while (a[i++]);
We want the loop to execute through encountering the zero character (which tests false) at the end of the string. That requires testing the value pre-increment and also incrementing the index. But not necessarily in that order - a way to code this with the pre-increment would be:
int i = -1;
do {
++i;
b[i] = a[i];
} while (a[i]);
It is a matter of taste which is clearer and if the machine has a handfull of registers both should have identical execution time, even if a[i] is a function that is expensive or has side-effects. A significant difference might be the exit value of the index.

Related

Using < or != in for loop termination condition

Given a vector v, I want to loop through each element in the vector and perform an operation that requires the current index.
I've seen a basic for loop written both of these ways:
// Using "<" in the terminating condition
for (auto i = 0; i < v.size(); ++i)
{
// Do something with v[i]
}
// Using "!=" in the terminating condition
for (auto i = 0; i != v.size(); ++i)
{
// Do something with v[i]
}
Is there any practical reason to prefer one over the other? I've seen it written using < much more often, but is there a performance benefit to using !=?
There is one, albeit kinda convoluted, reason to prefer < over !=.
If for whatever reason the body of your lop modifies i and skips over the threshold, < still terminates the loop, where != will keep iterating.
It might make no difference in the vast majority of cases, but getting used to < might prevent bugs that != won't. There's also an additional advantage, that is ridiculously minor but < takes less characters to write, so it makes the source file smaller.
Again the above argument is borderline a joke, but if you need an argument to use one over the other, there you have it.
You should probably prefer using a range-for instead.
Is there any practical reason to prefer one over the other?
There are no strong reasons to prefer one way or another given that both have equivalent behaviour.
Using the less than operator works even if the end condition is not one of the values of the accumulator which would be possible if increment was greater than 1 or the initial value was greater than the end condition. As such, it is more general, which means that using it always may be more consistent. Consistency is a weak argument, but a weak argument is better than no argument if you agree with it.
There is no difference in performance.
There is a huge difference if you decided to change ++i in such a way that the loop would step over the desired end.
For clarity for other programmers reading your code, use the convention they expect to see, namely <. When I see i != ..., I think "he is skipping over that one value".
The is an obscure bug with < -- Suppose you iterating over all 256 chars using a byte-sized i. The value will overflow and probably never show the value 256. The loop will never stop. And != won't fix the bug.

c++ : unsequenced modification and access to "i"

My ideas were quite simple.
I wish to copy element by element from vector temp to vector data.
void copy(vector<int> &data, vector<int> &temp)
{
int i=0;
while (i<data.size()) {
data[i]=temp[i++];//unsequenced modification and access to "i"
cout<<i<<endl;
}
Outputs:
temp={1,2,3,4}
but data={1,1,2,3}
even if i's cout values are 1,2,3,4
wonder why.
Thanks for help in advance!
The line
data[i]=temp[i++];//unsequenced modification and access to "i"
has undefined behavior. The result of executing the line will be different depending on whether data[i] is evaluated first or temp[i++] is evaluated first.
Use
while (i<data.size()) {
data[i]=temp[i];
++i;
}
As an alternative, use the std::copy function.
void copy(vector<int> &data, vector<int> &temp)
{
std::copy(temp.begin(), temp.end(), data.begin());
}
One might wonder why the behavior in a case like this isn't defined to be equivalent to incrementing in a separate statement following the one in question. I imagine the reason is that processors have some ability to do post increment for you (see the lodsw family of instructions). When using those instructions, the post increment must occur at the time you fetch the data. So to guarantee the post increment followed all other uses of the incremented variable would require that that fetch be done last, or at least after all other uses of the rsi in that statement. The designers probably decided that was too constraining.
Why people says about undefined behavior?
data[i]=temp[i++];
In this case, first, we will take value from temp[I] (example: y), then "i" will be incremented by 1 (i++), and after that, value from temp[i] (y in our case) will be stored in data[i], where "i" is already incremented by 1.

Is there a technical reason to use > (<) instead of != when incrementing by 1 in a 'for' loop?

I almost never see a for loop like this:
for (int i = 0; 5 != i; ++i)
{}
Is there a technical reason to use > or < instead of != when incrementing by 1 in a for loop? Or this is more of a convention?
while (time != 6:30pm) {
Work();
}
It is 6:31pm... Damn, now my next chance to go home is tomorrow! :)
This to show that the stronger restriction mitigates risks and is probably more intuitive to understand.
There is no technical reason. But there is mitigation of risk, maintainability and better understanding of code.
< or > are stronger restrictions than != and fulfill the exact same purpose in most cases (I'd even say in all practical cases).
There is duplicate question here; and one interesting answer.
Yes there is a reason. If you write a (plain old index based) for loop like this
for (int i = a; i < b; ++i){}
then it works as expected for any values of a and b (ie zero iterations when a > b instead of infinite if you had used i == b;).
On the other hand, for iterators you'd write
for (auto it = begin; it != end; ++it)
because any iterator should implement an operator!=, but not for every iterator it is possible to provide an operator<.
Also range-based for loops
for (auto e : v)
are not just fancy sugar, but they measurably reduce the chances to write wrong code.
You can have something like
for(int i = 0; i<5; ++i){
...
if(...) i++;
...
}
If your loop variable is written by the inner code, the i!=5 might not break that loop. This is safer to check for inequality.
Edit about readability.
The inequality form is way more frequently used. Therefore, this is very fast to read as there is nothing special to understand (brain load is reduced because the task is common). So it's cool for the readers to make use of these habits.
And last but not least, this is called defensive programming, meaning to always take the strongest case to avoid current and future errors influencing the program.
The only case where defensive programming is not needed is where states have been proven by pre- and post-conditions (but then, proving this is the most defensive of all programming).
I would argue that an expression like
for ( int i = 0 ; i < 100 ; ++i )
{
...
}
is more expressive of intent than is
for ( int i = 0 ; i != 100 ; ++i )
{
...
}
The former clearly calls out that the condition is a test for an exclusive upper bound on a range; the latter is a binary test of an exit condition. And if the body of the loop is non-trivial, it may not apparent that the index is only modified in the for statement itself.
Iterators are an important case when you most often use the != notation:
for(auto it = vector.begin(); it != vector.end(); ++it) {
// do stuff
}
Granted: in practice I would write the same relying on a range-for:
for(auto & item : vector) {
// do stuff
}
but the point remains: one normally compares iterators using == or !=.
The loop condition is an enforced loop invariant.
Suppose you don't look at the body of the loop:
for (int i = 0; i != 5; ++i)
{
// ?
}
in this case, you know at the start of the loop iteration that i does not equal 5.
for (int i = 0; i < 5; ++i)
{
// ?
}
in this case, you know at the start of the loop iteration that i is less than 5.
The second is much, much more information than the first, no? Now, the programmer intent is (almost certainly) the same, but if you are looking for bugs, having confidence from reading a line of code is a good thing. And the second enforces that invariant, which means some bugs that would bite you in the first case just cannot happen (or don't cause memory corruption, say) in the second case.
You know more about the state of the program, from reading less code, with < than with !=. And on modern CPUs, they take the same amount of time as no difference.
If your i was not manipulated in the loop body, and it was always increased by 1, and it started less than 5, there would be no difference. But in order to know if it was manipulated, you'd have to confirm each of these facts.
Some of these facts are relatively easy, but you can get wrong. Checking the entire body of the loop is, however, a pain.
In C++ you can write an indexes type such that:
for( const int i : indexes(0, 5) )
{
// ?
}
does the same thing as either of the two above for loops, even down to the compiler optimizing it down to the same code. Here, however, you know that i cannot be manipulated in the body of the loop, as it is declared const, without the code corrupting memory.
The more information you can get out of a line of code without having to understand the context, the easier it is to track down what is going wrong. < in the case of integer loops gives you more information about the state of the code at that line than != does.
As already said by Ian Newson, you can't reliably loop over a floating variable and exit with !=. For instance,
for (double x=0; x!=1; x+=0.1) {}
will actually loop forever, because 0.1 can't exactly be represented in floating point, hence the counter narrowly misses 1. With < it terminates.
(Note however that it's basically undefined behaviour whether you get 0.9999... as the last accepted number – which kind of violates the less-than assumption – or already exit at 1.0000000000000001.)
Yes; OpenMP doesn't parallelize loops with the != condition.
It may happen that the variable i is set to some large value and if you just use the != operator you will end up in an endless loop.
As you can see from the other numerous answers, there are reasons to use < instead of != which will help in edge cases, initial conditions, unintended loop counter modification, etc...
Honestly though, I don't think you can stress the importance of convention enough. For this example it will be easy enough for other programmers to see what you are trying to do, but it will cause a double-take. One of the jobs while programming is making it as readable and familiar to everyone as possible, so inevitably when someone has to update/change your code, it doesn't take a lot of effort to figure out what you were doing in different code blocks. If I saw someone use !=, I'd assume there was a reason they used it instead of < and if it was a large loop I'd look through the whole thing trying to figure out what you did that made that necessary... and that's wasted time.
I take the adjectival "technical" to mean language behavior/quirks and compiler side effects such as performance of generated code.
To this end, the answer is: no(*). The (*) is "please consult your processor manual". If you are working with some edge-case RISC or FPGA system, you may need to check what instructions are generated and what they cost. But if you're using pretty much any conventional modern architecture, then there is no significant processor level difference in cost between lt, eq, ne and gt.
If you are using an edge case you could find that != requires three operations (cmp, not, beq) vs two (cmp, blt xtr myo). Again, RTM in that case.
For the most part, the reasons are defensive/hardening, especially when working with pointers or complex loops. Consider
// highly contrived example
size_t count_chars(char c, const char* str, size_t len) {
size_t count = 0;
bool quoted = false;
const char* p = str;
while (p != str + len) {
if (*p == '"') {
quote = !quote;
++p;
}
if (*(p++) == c && !quoted)
++count;
}
return count;
}
A less contrived example would be where you are using return values to perform increments, accepting data from a user:
#include <iostream>
int main() {
size_t len = 5, step;
for (size_t i = 0; i != len; ) {
std::cout << "i = " << i << ", step? " << std::flush;
std::cin >> step;
i += step; // here for emphasis, it could go in the for(;;)
}
}
Try this and input the values 1, 2, 10, 999.
You could prevent this:
#include <iostream>
int main() {
size_t len = 5, step;
for (size_t i = 0; i != len; ) {
std::cout << "i = " << i << ", step? " << std::flush;
std::cin >> step;
if (step + i > len)
std::cout << "too much.\n";
else
i += step;
}
}
But what you probably wanted was
#include <iostream>
int main() {
size_t len = 5, step;
for (size_t i = 0; i < len; ) {
std::cout << "i = " << i << ", step? " << std::flush;
std::cin >> step;
i += step;
}
}
There is also something of a convention bias towards <, because ordering in standard containers often relies on operator<, for instance hashing in several STL containers determines equality by saying
if (lhs < rhs) // T.operator <
lessthan
else if (rhs < lhs) // T.operator < again
greaterthan
else
equal
If lhs and rhs are a user defined class writing this code as
if (lhs < rhs) // requires T.operator<
lessthan
else if (lhs > rhs) // requires T.operator>
greaterthan
else
equal
The implementor has to provide two comparison functions. So < has become the favored operator.
There are several ways to write any kind of code (usually), there just happens to be two ways in this case (three if you count <= and >=).
In this case, people prefer > and < to make sure that even if something unexpected happens in the loop (like a bug), it won't loop infinitely (BAD). Consider the following code, for example.
for (int i = 1; i != 3; i++) {
//More Code
i = 5; //OOPS! MISTAKE!
//More Code
}
If we used (i < 3), we would be safe from an infinite loop because it placed a bigger restriction.
Its really your choice whether you want a mistake in your program to shut the whole thing down or keep functioning with the bug there.
Hope this helped!
The most common reason to use < is convention. More programmers think of loops like this as "while the index is in range" rather than "until the index reaches the end." There's value is sticking to convention when you can.
On the other hand, many answers here are claiming that using the < form helps avoid bugs. I'd argue that in many cases this just helps hide bugs. If the loop index is supposed to reach the end value, and, instead, it actually goes beyond it, then there's something happening you didn't expect which may cause a malfunction (or be a side effect of another bug). The < will likely delay discovery of the bug. The != is more likely to lead to a stall, hang, or even a crash, which will help you spot the bug sooner. The sooner a bug is found, the cheaper it is to fix.
Note that this convention is peculiar to array and vector indexing. When traversing nearly any other type of data structure, you'd use an iterator (or pointer) and check directly for an end value. In those cases you have to be sure the iterator will reach and not overshoot the actual end value.
For example, if you're stepping through a plain C string, it's generally more common to write:
for (char *p = foo; *p != '\0'; ++p) {
// do something with *p
}
than
int length = strlen(foo);
for (int i = 0; i < length; ++i) {
// do something with foo[i]
}
For one thing, if the string is very long, the second form will be slower because the strlen is another pass through the string.
With a C++ std::string, you'd use a range-based for loop, a standard algorithm, or iterators, even if though the length is readily available. If you're using iterators, the convention is to use != rather than <, as in:
for (auto it = foo.begin(); it != foo.end(); ++it) { ... }
Similarly, iterating a tree or a list or a deque usually involves watching for a null pointer or other sentinel rather than checking if an index remains within a range.
One reason not to use this construct is floating point numbers. != is a very dangerous comparison to use with floats as it'll rarely evaluate to true even if the numbers look the same. < or > removes this risk.
There are two related reasons for following this practice that both have to do with the fact that a programming language is, after all, a language that will be read by humans (among others).
(1) A bit of redundancy. In natural language we usually provide more information than is strictly necessary, much like an error correcting code. Here the extra information is that the loop variable i (see how I used redundancy here? If you didn't know what 'loop variable' means, or if you forgot the name of the variable, after reading "loop variable i" you have the full information) is less than 5 during the loop, not just different from 5. Redundancy enhances readability.
(2) Convention. Languages have specific standard ways of expressing certain situations. If you don't follow the established way of saying something, you will still be understood, but the effort for the recipient of your message is greater because certain optimisations won't work. Example:
Don't talk around the hot mash. Just illuminate the difficulty!
The first sentence is a literal translation of a German idiom. The second is a common English idiom with the main words replaced by synonyms. The result is comprehensible but takes a lot longer to understand than this:
Don't beat around the bush. Just explain the problem!
This is true even in case the synonyms used in the first version happen to fit the situation better than the conventional words in the English idiom. Similar forces are in effect when programmers read code. This is also why 5 != i and 5 > i are weird ways of putting it unless you are working in an environment in which it is standard to swap the more normal i != 5 and i < 5 in this way. Such dialect communities do exist, probably because consistency makes it easier to remember to write 5 == i instead of the natural but error prone i == 5.
Using relational comparisons in such cases is more of a popular habit than anything else. It gained its popularity back in the times when such conceptual considerations as iterator categories and their comparability were not considered high priority.
I'd say that one should prefer to use equality comparisons instead of relational comparisons whenever possible, since equality comparisons impose less requirements on the values being compared. Being EqualityComparable is a lesser requirement than being LessThanComparable.
Another example that demonstrates the wider applicability of equality comparison in such contexts is the popular conundrum with implementing unsigned iteration down to 0. It can be done as
for (unsigned i = 42; i != -1; --i)
...
Note that the above is equally applicable to both signed and unsigned iteration, while the relational version breaks down with unsigned types.
Besides the examples, where the loop variable will (unintentional) change inside the body, there are other reasions to use the smaller-than or greater-than operators:
Negations make code harder to understand
< or > is only one char, but != two
In addition to the various people who have mentioned that it mitigates risk, it also reduces the number of function overloads necessary to interact with various standard library components. As an example, if you want your type to be storable in a std::set, or used as a key for std::map, or used with some of the searching and sorting algorithms, the standard library usually uses std::less to compare objects as most algorithms only need a strict weak ordering. Thus it becomes a good habit to use the < comparisons instead of != comparisons (where it makes sense, of course).
There is no problem from a syntax perspective, but the logic behind that expression 5!=i is not sound.
In my opinion, using != to set the bounds of a for loop is not logically sound because a for loop either increments or decrements the iteration index, so setting the loop to iterate until the iteration index becomes out of bounds (!= to something) is not a proper implementation.
It will work, but it is prone to misbehavior since the boundary data handling is lost when using != for an incremental problem (meaning that you know from the start if it increments or decrements), that's why instead of != the <>>==> are used.

When using inside a for-loop, is there any exception or even extreme corner case that postincrement is actually better than preincrement?

Consider the following statements:
for (Container<Object>::Iterator it = container.begin(); it != container.end(); it++) {
*loop_content*
}
vs.
for (Container<Object>::Iterator it = container.begin(); it != container.end(); ++it) {
*loop_content*
}
From my understanding, regardless what *loop_content* is, when used inside a for-loop like the example above, the preincrement version is guaranteed to be not worse than the postincrement version. Is there any exception or even extreme corner case that make this statement no longer true and make postincrement is actually better than preincrement?
If not so, here is my slightly off-topic second question which I have been wondering for years: Why a lot text books are teaching people to use for-loop with example like:
for (int i = 0; i < 42; i++)
not
for (int i = 0; i < 42; ++i)
My guess is that there are some medieval languages only have i++ but not ++i implemented so that people who used to these languages stay with the way they increment iterators, but I really want to know where this convention come from.
To elaborate on my comment, a for loop like
for (pre; cond; post) body
is equivalent to the following while loop
{
pre
while (cond)
{
body
post
}
}
As you can see, the post part, while inside the while loop body, is separate from the for loop body.
Usually post-increment and pre-increment differ in only two respects: they return a different value, and post-increment is slightly more expensive because it requires making a copy of the variable. The return value is not used in a for loop, so if we want post- to be better than pre-, we must invent a new Container class whose Iterator has a weird and costly pre-increment operator. Something like
operator++()
{
ptr = ptr->next;
// perform some undefined behavior, or just hash the Beijing telephone book
return *this;
}
This can be done as a result of simple incompetence. As for a real reason to put something bad in operator++(), I'm stumped.
P.S. I had a subordinate once who insisted that post-increment was correct, and that using pre-increment in the for loop would give different (wrong) results. Repeatedly correcting him didn't help; the fact that he could have tested this hypothesis very easily made no difference. He had somehow worked as a software engineer for over ten years without getting good at it.

which is better "for(int i = 0; i != 5; ++i)" or "for(int i = 0; i <= 5; i++)"? [duplicate]

This question already has answers here:
Why do c++ programmers use != instead of <
(7 answers)
Closed 3 years ago.
which is better for(int i = 0; i != 5; ++i) or for(int i = 0; i <= 5; i++)?
Please explain the rationale, if possible.
I read somewhere that != operator is better than comparison operators. also pre-increment operator is better than post-increment operator, since it doesn't require any temporary variable to store the intermediate value.
Is there any better form of for loop than these two?
p.s: I use the former one as suggested by one of the sources, which i don't remember now.
There are at least two differences:
the first one will iterate 5 times (from 0 to 4), while the second one will iterate 6 times (from 0 to 5).
This is a logic difference, and it depends on what you need to do.
If what you meant for the second example was i<=4 (versus i!=5) you shouldn't bother: any compiler will always be able to optimize such a trivial expression even with optimizations turned off.
the second difference is the use of operator ++: in a case you use the prefix version, while in the other the postfix version.
This doesn't make difference for native types, but could do some difference with user defined types (ie classes, structs, enums, ...), since the user could overload the operator, and the postfix one (var ++) could be a little slower sometimes.
Using "i < 5" would be the form most people would expect to see on a for loop based on common usage. There is nothing wrong of course with "i != 5" or "i <= 5" (expect they'll give different loop counts) but if I see either of those forms I have to stop and think because it's not the most common form.
So I would always write "i < 5" unless there was a strong reason to do otherwise
Generally, you should write for PEOPLE not the computer.
The "for(i = 0; i < 5; i++)" form makes it very clear that the valid range is "0 through 4" and nothing else.
And as other people said, this form make sure that funny code in the loop is much less likely to cause an infinite loop. And as other people have said, use the form that reflects what you mean.
Note that "less than" is the idiom commonly used in c (which means more programmers will expect that). That's another reason to prefer the "for(i = 0; i < 5; i++)" form.
My teacher in the C++ language told me to use the canonical forms: for(int x=0; x != 5; ++i)
Thou the other works just fine but suppose you want to use the loop on a iterator. Then <= does not has to be properly defined and a postfix inc might make your program spend alot of time copying objects.
So he made us use the forms
for(int i=begin; x != end; ++i) and for(int i=begin; end != i--; )
which is better for(int i = 0; i != 5; ++i) or for(int i = 0; i <= 5; i++)?
the 2nd one since its a Bolian Operator, then this for(int i = _ ; i <= __ or etc ; i++ increment )? --> it's widely used as now a days even when are beginners in programming.
You should use whichever of <, <=, != etc. best expresses your application logic, but if there's no reason to prefer any particular style, then be consistent. In informing that decision, the < and != operators have the advantage of allowing comparisons between 0-based indices and sizeof or STL-style size / length values, as in:
for (size_t i = 0; i < my_vector.size(); ++i)
...
The < and <= operators sometimes guard against incrementing past the terminating value (if you've got another condition inside the loop under which you increment/add-to i, or there's some floating point rounding/representation disparity). Not often actually significant, but saving an occasional bug is better than nothing.
Given '<' is the intersection of these two sets, it's a popular choice. To my mind, < also communicates the states under which the loop runs... a more positive assertion rather than the != style. In general, negative assertions are discouraged in programming (e.g. bool invalid is more complicated to get your head around reliably than bool valid, especially in complex boolean expression and when double-negatives are introduced).
This is of course for numeric types. Other types may imply other styles... for example, use of != sentinel. I prefer to have the choice of operator help document these usage implications of the type, though that's a personal choice and arguably redundant.
Otherwise, preincrement can be more efficient for complicated types than post- as it avoids a temporary.
The condition != is simply faster than both < and (even more) <= otherwise it is just question of taste, though one needs to be careful of possible infinite loops.