Thread: Can I rely on the condition of a for loop to be re-evaluated ?

O_o

That's almost certainly not going to be "optimized" away; it is possible I supposed, but I feel safe with that.

That said, that's really the wrong way to go about that conceptual model; you should instead consider using an insertion iterator.

Soma

Originally Posted by phantomotap

That said, that's really the wrong way to go about that conceptual model; you should instead consider using an insertion iterator.

This was just an example snippet.
I'm thinking of circumstances, when actual iteration is needed and the current element is 'somehow' used.

I'm thinking of circumstances, when actual iteration is needed and the current element is 'somehow' used.

I realize that it was an example.

It just happens that the model here is pretty common.

My point was that using actual iterators for iteration is usually a little better.

Soma

Originally Posted by phantomotap

My point was that using actual iterators for iteration is usually a little better.

What ?
Now I'm confused. :S

Now I'm confused.

The actual loop body isn't using iterators. You are using the container directly.

You are using iterators to control the range. That is all.

What you are doing is equivalent to just using `std::vector<???>::size()' and a counter to control the range.

I'm saying that actually using iterators to access and modify container elements is usually a little better.

Soma

Originally Posted by phantomotap

The actual loop body isn't using iterators. You are using the container directly.

Code:

for(auto x = vi.begin(); x!=vi.end(); x++)

Err..
x is an iterator here.
The loop body could use *x for whatever purpose necessary.
My question was if the evaluation of "x!=vi.end()" is mandatory for every cycle of the loop.

x is an iterator here.

You are clearly not listening to hints so I'll just bash you over the freaking head!

The iterator `x' may be invalidated; the instant `x' becomes invalid the code breaks. The code breaks because `x' is not an actual iterator when you've invalidated it; it is an iterator in name only; it is exactly equivalent to using a random pointer. You need to use an actual iterator.

I'm telling you that you need to use iterators correctly. I don't know why you aren't getting that.

*shrug*

Maybe I should have just smacked you with it from the start.

The model you've employed here is fine. The code is broken. It isn't broken because of the compiler optimizing out the loop condition. It is broken because you aren't using an actual iterator into the `std::vector<???>'. Every time `std::vector<???>:ush_back()' is called you may invalidate `x'. The iterator points to the old memory area owned by the `std::vector<???>'; the operation `std::vector<???>:ush_back()' may move that memory.

So, here is what you need to do, read the documentation for every method of every container you use and see which operations may invalidate iterators. If you invalidate an iterator, you may not use it for anything.

Soma

Got it .. :P
I'm still in the dark about what you mean by "actual iterators".
If the iterators is going to be invalidated when the vector's data is moved into a bigger memory area,
isn't it just simpler using plain counter variables and a "x < vi.size()" condition to manage the loop?

There'd be no chance of invalidated iterators then.... but I would be paranoid enough to consider x not getting updated.

There'd be no chance of invalidated iterators then.... but I would be paranoid enough to consider x not getting updated.

Well, you would probably not have the chance of invalidating iterators, but you would of course still need to be careful.

Take the code you posted as yet another reason why programming isn't always simple.

If you simply swapped out the code with a counter and `std::vector<???>::size()' you might wind up with an infinite loop. The vector could grow by one every iteration triggering another iteration.

So, changing to a counter doesn't guarantee that the code will behave reasonably and correctly.

Using iterators, correctly mind, is usually better.

Soma

Originally Posted by phantomotap

Using iterators, correctly mind, is usually better.

I can't think of a way to do that but "vi.begin() + counter" but that would be quite redundant as vi[counter] gets the same thing.

As always, you take examine the problem and figure out what works to solve it.

If you understand how and when the iterators are invalidated you can easily write code to prevent these problems.

Take this model for example, you setup your range properly and by using an insertion iterator can write very clear code for the loop body.

Code:

int s(rand() % 6);
if((s==1) || (s==4))
{
    *it++ = s;
}

The code to setup the range is as easy as getting the range iterators from the `std::vector<???>'.

The code to prevent the iterators from becoming invalid is as simple as measuring the difference between the size and the capacity and adjusting the capacity for the worse case scenario.

This assumes you need to use the original `std::vector<???>'. Using secondary storage and splicing the storage together is probably the better option in general.

Soma