Difference in STL implementations...

This is a discussion on Difference in STL implementations... within the C++ Programming forums, part of the General Programming Boards category; At school here compiling with dev-cpp I'm getting strange results in my program.
I'm using STL <list>. Now at home ...

Difference in STL implementations...

At school here compiling with dev-cpp I'm getting strange results in my program.

I'm using STL <list>. Now at home using g++ 4.2.3 (or whatever the latest version is) it seems it treats the end of the list differently, than it's being treated using dev-cpp (don't know which version of g++ or mingw it is).

Well quite frankly, it is treating it differently. As my main program loop get's back to the end of the list it treats:

it = mlist.end();

as if it were:

it = mlist.begin();

I know it's doing this, because my code has worked w/out problem with the latest version of g++.

Bugs in the implementation aside, the observable behaviour of the STL is clearly defined by the standard, with no leeway. A list is not circular. You simply have a bug, and for whatever reason, it didn't show up until now. But it's definitely a bug. And I have no idea how it could ever work for you.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

After going ++it, you're not allowed to dereference it unless you have determined that it is not equal to end(). You should check that.
For that matter you should also be careful to ensure that when you dereference it before the ++it, that it was not already equal to end().

Is this for a triangle clipper in a software 3D engine? I would suggest using a vector of vertex indexes instead of a list, if it is.

So you want to jump back to the beginning of the list when you reach end?

Without code reduplication you could use

Code:

if (it == l.end()) it = l.begin();

And carry on as normal.

The difference is that the iterator returned by end shouldn't be used for anything else than testing if you have reached the end of the container. You shouldn't dereference it and you shouldn't try to increment it.

Your function would work now as long as you don't pass it an end() iterator initially.

Do you really think it's wise for a function to increment the iterator like that? Normally you would call this function from inside of a loop that owned the iterator and simply passed it to this function. That way you would have the correct iterator upon entry to the function. And you can guarantee that if you have an iterator related bug you know it's in the function that contains the loop code, not in this function. Iterating like this could introduce several problems into your code.

I normally try to increment iterators in exactly one place so that they are not getting incremented and altered all over my code.

Code:

while (iter != m_mylist.end())
{
SomeFunc(iter);
++iter;
}

SomeFunc here would not alter the iterator which delegates this responsiblity back to the code that really should increment the iterator. You currently have this:

Code:

while (iter != m_mylist.end())
{
iter = SomeFunc(iter);
}

It is not apparent here that the iterator is getting incremented. It's not hard to deduce, but who knows what SomeFunc() is doing with the iterator? The logic for incrementing is hidden inside of SomeFunc(). You could really run into trouble if SomeFunc() erased something from the list.