iterator vs old-style c-code

**curos** · 07-04-2005

I was just reading the article on iterators at Cprogramming and I was wondering why they recommend the STL approach instead of the old C approach. Why is one better than the other? I am more familiar with the old method.

The two styles are reproduced here exactly as seen in the article:

The old approach

Code:

using namespace std;

vector<int> myIntVector;
// Add some elements to myIntVector
myIntVector.push_back(1);
myIntVector.push_back(4);
myIntVector.push_back(8);

for(int y=0; y<myIntVector.size(); y++)
{
    cout<<myIntVector[y]<<" ";
    //Should output 1 4 8
}

STL approach

Code:

using namespace std;

vector<int> myIntVector;
vector<int>::iterator myIntVectorIterator;

// Add some elements to myIntVector
myIntVector.push_back(1);
myIntVector.push_back(4);
myIntVector.push_back(8);

for(myIntVectorIterator = myIntVector.begin(); 
        myIntVectorIterator != myIntVector.end();
        myIntVectorIterator++)
{
    cout<<*myIntVectorIterator<<" ";
    //Should output 1 4 8
}

**~~ILoveVectors~~** · 07-04-2005

I think it is because using i you could possibly go out of the vector
boundries, with the iterator you cant.

**Micko** · 07-04-2005

I think it is recommended because of consistency when using STL containers. Iterators offers unique approach and pretty much same interface whether you're working with vectors, lists, maps etc...
Also, I believe, some containers cannot support random access via operator[ ] although I'm not sure since I'm beginer in STL.

- Micko

**JoshR** · 07-04-2005

Originally Posted by article

The Gotchas

* Iterators do not provide bounds checking; it is possible to overstep the bounds of a container, resulting in segmentation faults
* Different containers support different iterators, so it is not always possible to change the underlying container type without making changes to your code
* Iterators can be invalidated if the underlying container (the container being iterated over) is changed significantly

That was from the article.

**CornedBee** · 07-04-2005

It's still a matter of consistency in the code. The simple forward container iteration, the most basic of for loops, in your example looks exactly the same for all iterator-supporting containers, and that includes Boost.Array, which is a thin wrapper over the built-in array. The same cannot be said for the indexing access - you can use that for vector and deque, but it will fail for all standard other containers.
The point of iterators is that they provide a uniform syntax for common operations of containers. Of course, code that relies on specific features of specific containers is no longer container-independent.
Yes, iterators can be invalidated. So can indexes, although not as easily. Take for example the vector. An iterator is invalidated if:
1) Elements are inserted so that the size exceeds the capacity - the vector will have to reallocate, thus invalidating all iterators. Indices are not invalidated.
2) Elements are inserted at or before the iterator location. The iterator is invalidated because it no longer points to the original element. The same applies to indices.
3) Elements are removed at or before the iterator location. The iterator is invalidated because it no longer points to the original element. The same applies to indices.

So you see, most of the situations that invalidate iterators invalidate indices as well.

Thread: iterator vs old-style c-code

Thread Tools

Search Thread

Display

iterator vs old-style c-code

Similar Threads

Binary Search Trees Part III

Problem : Threads WILL NOT DIE!!

True ASM vs. Fake ASM ????

Interface Question

Can you have nested code block? What does the compiler do? For example ...