What exactly is iterator returned by .end()?

**matsp** · 12-09-2008

@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

**C_ntua** · 12-09-2008

Originally Posted by Elysia

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?

**laserlight** · 12-09-2008

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.

**pheres** · 12-09-2008

Originally Posted by matsp

@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.

**laserlight** · 12-09-2008

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.

**matsp** · 12-09-2008

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

**pheres** · 12-09-2008

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

Thread: What exactly is iterator returned by .end()?

Thread Tools

Search Thread

Display