Re: Does std::unique invalidate iterators ever?
Alan Woodland wrote:
Is this well defined behaviour?
#include <vector>
#include <string>
#include <algorithm>
int main() {
std::vector<std::string> content;
content.push_back("foo");
content.push_back("bar");
content.push_back("foo");
// make sure the content is unique, discard any duplicates
std::sort(content.begin(), content.end());
content.erase(std::unique(content.begin(), content.end()),
content.end());
return 0;
}
My concern is that the order of evaluation of the arguments passed to
erase() is unspecified, and therefore that unique could invalidate the
iterator returned by end(). If I've understood things correctly then
unique can't invalidate any iterators and so the example code is well
defined?
Usually in the Standard any iterator invalidations are explicitly
stated. Since for 'unique' nothing is mentioned, I'd say that iterators
are not invalidated. The elements can get different values, yet
whatever points to them will still be OK to dereference, increment,
decrement, or pass to algorithms expecting an iterator. With the vector
the 'end' stays "one past last" except when it reallocates or elements
are erased. Since no elements are erased during 'unique', you should be OK.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask