iterator vs old-style c-code

This is a discussion on iterator vs old-style c-code within the C++ Programming forums, part of the General Programming Boards category; I was just reading the article on iterators at Cprogramming and I was wondering why they recommend the STL approach ...

  1. #1
    Registered User
    Join Date
    Jul 2005
    Posts
    4

    iterator vs old-style c-code

    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
    }

  2. #2
    Banned
    Join Date
    Jun 2005
    Posts
    594
    I think it is because using i you could possibly go out of the vector
    boundries, with the iterator you cant.

  3. #3
    Registered User Micko's Avatar
    Join Date
    Nov 2003
    Posts
    712
    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
    Gotta love the "please fix this for me, but I'm not going to tell you which functions we're allowed to use" posts.
    It's like teaching people to walk by first breaking their legs - muppet teachers! - Salem

  4. #4
    *this
    Join Date
    Mar 2005
    Posts
    498
    Quote 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.
    Last edited by JoshR; 07-04-2005 at 02:47 PM.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Binary Search Trees Part III
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 10-02-2004, 03:00 PM
  2. Problem : Threads WILL NOT DIE!!
    By hanhao in forum C++ Programming
    Replies: 2
    Last Post: 04-16-2004, 01:37 PM
  3. True ASM vs. Fake ASM ????
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 04-02-2003, 03:28 AM
  4. Interface Question
    By smog890 in forum C Programming
    Replies: 11
    Last Post: 06-03-2002, 05:06 PM
  5. Replies: 4
    Last Post: 01-15-2002, 11:04 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21