It depends on the context, but one reason != is sometimes used instead of < is that in the context of iterating over the elements in a container, != is more general. As an example, a generic function that iterates over the elements in a container using != as the conditional will work with (e.g.) both vector and map, whereas if < were used, the function would not work with map. Another way to look at it is that != will work with more types of iterators than will <.

In your example above, clearly != would not be the right choice (again, which to use depends on the context).

Quote:Original post by Dbproguy

What if you set up a for loop as such:
for (int i = 0; i != 11; i += 2)
then you've got a problem, because i will never equal 11.

You've got a problem either way. If you're iterating over only the even numbers in a range, and that range may be of a size which is an odd number, then you had better think hard about what should be done in that situation. Using < instead of != would certainly hide the problem, but it wouldn't necessarily fix it. In general, the kind of bugs that you WANT to have are the ones that result in obvious problems. It's the ones that are less visible that are the real time sinks. From that perspective, using != instead of < is a good thing to do, because it doesn't hide the sort of problem you posted.

Quote:Original post by Dbproguy
What would be the solution to iterating through the even numbered indexes of a container with an odd number? Would you just have to check and see if it has an odd number first then if it does, iterate to (x.end()-1)?

It seems you missed the point.

Which one you use depends entirely on your algorithm.

If your algorithm must run less than x, use < x.
If your algorithm must run to the end of the iterator, use != foo.end().
If your algorithm must run as long as something is true, use x == true.
If you algorithm must run for {whatever}, use {the thing that does it}.


So if your algorithm has a requirement that the iterator have an even number of elements, it is your job to ensure this is the case. If your algorithm needs different logic to handle even and odd element counts, it is your job to ensure that it does.

If you need to advance an iterator more than one space, you can use std::advance() to move it. It is still your responsibility to ensure that you do not advance past the end of the container. Just note that if you iterate past the end of the iterator, your results are undefined. The standards committee intentionally left out requirements about what to do when you iterate past the end --- there are potential performance issues and they do not like forcing extra costs when it can be avoided.



The answer to your particular problem seems obvious to me:

Rather than incrementing directly inside the loop, consider writing a small function/functor/predicate/whatever that does this for you. This can advance it once, and if the result != iter.end(), advance it a second time. You could get fancy and have one that advances n times. Basically implement std::advance() with an end-of-iterator safety check.





For iterators, know that ordering is undefined. For any iterator, .begin() is not always before .end(). Reverse iterators go from back to front. Several standard containers operate in blocks so the data can be allocated in just about any configuration. I have seen several different circular buffer containers with an iterator that loops in the middle. In each case, ordering may not be what you expect.

Many beginners think of iterators in the format {front,...,end}. They need to revise their thinking. There are iterators that travel in reverse {end,...,front}, circular {...,end,empty,front,...}, block allocations {...,begin,...,end,...}, and just about any other configuration imaginable.

Because iterator ordering is undefined, you should always compare directly against .begin() and .end().

If you consider data corruption from external sources, then what do you do about code that gets corrupted? ;)

If you want to hide it from the customer, but see it in development, why not:

assert(maxI % 2 == 0); // or your choice of debug-build-only error catchingfor(int i = 0; i <= maxI; i += 2)    // ...

?