What exactly is iterator returned by .end()?

This is a discussion on What exactly is iterator returned by .end()? within the C++ Programming forums, part of the General Programming Boards category; @Pheres: What are you actually trying to achieve? Check that something got added? If so, why not take the size() ...

  1. #16
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    @Pheres: What are you actually trying to achieve? Check that something got added? If so, why not take the size() of the vector, and compare it later on?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  2. #17
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Quote Originally Posted by Elysia View Post
    Code:
    #include <vector>
    #include <iostream>
    
    using namespace std;
    
    int main()
    {
    	vector<int> v;
    	v.push_back(1);
    	vector<int>::iterator end = v.end();
    	v.push_back(2);
    	vector<int>::iterator it;
    	for (it = v.begin(); it != end ; it++)
    		cout << *it;
    }
    Output:
    Well, nothing.
    Visual Studio pops up a nasty dialog says "vector iterators incompatible."
    So don't count on doing something like this. When you add or delete from a vector, assume that the iterators are invalidated.
    Just out of curiosity, why are the iterators incompatible?

  3. #18
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    Quote Originally Posted by C_ntua
    Just out of curiosity, why are the iterators incompatible?
    Since reallocation presumably occurred, the underlying pointers do not point to somewhere in the same dynamically allocated array (or one past the end), hence they cannot be validly compared.

    EDIT:
    No, I recall wrongly: pointers that point to elements from different arrays cannot be validly subtracted, but there is no restriction on comparison. On the other hand, since we are talking about iterators, the fact that the underlying array is different could be sufficient for us to call the iterators incompatible by definition.
    Last edited by laserlight; 12-09-2008 at 07:45 AM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #19
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by matsp View Post
    @Pheres: What are you actually trying to achieve? Check that something got added? If so, why not take the size() of the vector, and compare it later on?

    --
    Mats
    I've some list (not vector in my case) of objects and 2 free iterators which mark begin and end of a range of objects which shall asynchronously (to the computation of the two iterators) be processed in the next slice of time.
    Also asynchronously objects can be added as well as removed, so the iterators have to be recomputed in this case to keep the system stable.
    Thats why I wanted to know if I have to check if an iterator coincidentaly pointing to end() has to be recomputed after adding objects (to the end if the list) or not.

  5. #20
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    Quote Originally Posted by pheres
    Thats why I wanted to know if I have to check if an iterator coincidentaly pointing to end() has to be recomputed after adding objects (to the end if the list) or not.
    Adding elements to a std::list does not invalidate existing iterators. Erasing elements from a std::list only invalidates iterators to the erased elements. Unfortunately, I am not sure what exactly is the definition of a "valid iterator". Clearly, an iterator that refers to an existing element is valid, but I am not sure if a past-the-end iterator is considered valid.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #21
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Am I right in thinking that there is two (or more) threads potentially accessing the same container at the same? That seems like a VERY BAD IDEA(tm).

    There is nothing in the standard that guarantees that the STL containers are in the least way thread-safe. You may be operating on elements in a vector, and all of a sudden the vector is being re-arranged and the elements are now in a completely different place. Linked lists are equally dodgy - you may be going to the next element, which is currently being deleted by the other thread (or an element inserted in front of).

    Your are playing with matches and petrol - it's going to burn you sooner or later.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #22
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    the list access is synchronized while receiving references to it's elements or computation of the iterators or adding/removing elements and only unlocked while processing the received elements. this is just the normal thread pool pattern with nothing very special about it. i tested it on multicore machine under heavy load. the synch should be ok.
    I only thought about saving the check for the iterator returned by .end() as a special case
    Last edited by pheres; 12-09-2008 at 08:54 AM.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

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