Accessing iterator past the end of a list

[Brick86]

Hi all,
I'm trying to understand the code at the bottom of my post. I am working with a someone else's code and don't have a lot of experience in C++. My problem is that in the second loop it is accessing a field in an object pointed to by the first iterator. However, surely this iterator is now equal to the end of the array as it is the exit condition of the first loop.

Would someone be able to explain to me how this is working?

Any help would be much appreciated. Thanks.

for(iter=M.mappings.begin(); iter!=M.mappings.end(); iter++)	{
	another.erase(iter->target);
	s<< "\t\tdb"<<iter->target<<" [label=\""<<G2->getNodeAttrs(iter>source)->find("name")->second.value<<"\" shape=box style=filled fillcolor=lightblue color=blue];\n";		
}
		
for(p1=another.begin(); p1!=another.end(); p1++)
{
	s<< "\t\tdb"<< (*p1)<<" [label=\""<<G2->getNodeAttrs(iter->source)- >find("name")->second.value<<"\" shape=box];\n";

[Lindley]

Indeed, that seems like an error. Note also this bit: "G2->getNodeAttrs(iter>source)" seems to be saying something other than it intends as well.

[Paul McKenzie]

Would someone be able to explain to me how this is working?

When a mistake such as this is made in a C++ program, nothing guarantees that the application will behave in a strange manner. Therefore the program seems to "work", but internally it has a bug.

Having said that, many compilers will check iterator validity when compiled with "debugging" turned on.

Regards,

Paul McKenzie

[Moschops]

For a long time, the MS compiler that shipped with VS would happily let you do things you shouldn't with off-the-end iterators. As I recall, under the hood, iterators were being implemented to some degree as pointers, so you could quite happily read invalid data and be none the wiser.

I wouldn't be surprised if other compilers of the era exhibited similar oddities

[itsmeandnobodyelse]

As I recall, under the hood, iterators were being implemented to some degree as pointers

Not only to some degree, but they simply were typedefs of a pointer type, e. g. std::vector<T>::iterator of Visual C++ 6.

But here we seem to have a std::map and that could not be done by a simple pointer. So I would assume the 'another' was empty when reaching the second loop and hence it didn't crash.