[unordered] Iterator default constructor usage
Hi all. Is it a correct usage of default constructor of iterators? Are any gurantees that it will always equals to the iterator returned by end()? : typedef boost::unordered_map<std::string, int> map; map x; x["one"] = 1; assert(x.find("missing") == x.end()); assert(x.find("missing") == map::iterator()); assert(map::iterator() == x.end()); Andrey
On Nov 25, 2011, at 1:07 PM, andpar83@gmail.com wrote:
Hi all.
Is it a correct usage of default constructor of iterators? Are any gurantees that it will always equals to the iterator returned by end()? :
typedef boost::unordered_map<std::string, int> map; map x; x["one"] = 1;
assert(x.find("missing") == x.end()); assert(x.find("missing") == map::iterator()); assert(map::iterator() == x.end());
How could they be? Consider the following code: std::vector<int> v1, v2; std::vector::iterator i1; Should i1 == v1.end () or i1 == v2.end () be true? (they cannot both be true) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 25 November 2011 22:09, andpar83@gmail.com <andpar83@gmail.com> wrote:
It's the reason why I'm asking this. Now it's working.
In 1.48, the end iterator just contains a null pointer, which is why that currently works. This might not always be the case, so it isn't guaranteed. For example, the data structure might change, or the iterator might be changed so that it's a POD and isn't default initialised.
participants (3)
-
andpar83＠gmail.com -
Daniel James -
Marshall Clow