@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
@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.
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.Originally Posted by C_ntua
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 08:45 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
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.Originally Posted by pheres
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
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 09:54 AM.