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

This is a discussion on Can I rely on the condition of a for loop to be re-evaluated ? within the C++ Programming forums, part of the General Programming Boards category; I'm almost certain that I can rely on it, but just to be sure...
For example:
Code:
int main()
{
...

It iterates over the modified vector in my case. (even after changing some compiler options manually).
Is that standard/portable behaviour or is the compiler free to stop iterating at the original end iterator ?
Does volatile solve anything if the later is the case ?

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

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.

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.

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !