This chapter is from the book
This chapter is from the book
This chapter is from the book
Examples
Example 1: Using an invalid iterator . It's easy to forget when iterators are invalidated and use an invalid iterator (see Item 99). Consider this example adapted from [Meyers01] that inserts elements at the front of a deque :
deque<double>::iterator current = d.begin(); for( size_t i = 0; i < max; ++i ) d.insert( current++, data[i] + 41 ); // do you see the bug?
Quick: Do you see the bug? You have three seconds.—Ding! If you didn't get it in time, don't worry; it's a subtle and understandable mistake. A checked STL implementation will detect this error for you on the second loop iteration so that you don't need to rely on your unaided visual acuity. (For a fixed version of this code, and superior alternatives to such a naked loop, see Item 84.)
Example 2: Using an iterator range that isn't really a range. An iterator range is a pair of iterators first and last that refer to the first element and the one-past-the-end-th element of the range, respectively. It is required that last be reachable from first by repeated increments of first . There are two common ways to accidentally try to use an iterator range that isn't actually a range: The first way arises when the two iterators that delimit the range point into the same container, but the first iterator doesn't actually precede the second:
for_each( c.end(), c.begin(), Something ); // not always this obvious
On each iteration of its internal loop, for_each will compare the first iterator with the second for equality, and as long as they are not equal it will continue to increment the first iterator. Of course, no matter how many times you increment the first iterator, it will never equal the second, so the loop is essentially endless. In practice, this will, at best, fall off the end of the container c and crash immediately with a memory protection fault. At worst, it will just fall off the end into uncharted memory and possibly read or change values that aren't part of the container. It's not that much different in principle from our infamous and eminently attackable friend the buffer overrun.
The second common case arises when the iterators point into different containers:
for_each( c.begin(), d.end(), Something ); // not always this obvious
The results are similar. Because checked STL iterators remember the containers that they refer into, they can detect such run-time errors.