stl vector iterator windows linux

[jimc]

The code does exactly the same thing. Lines 10-15 are the same as lines 16-21.

So what?

To clarify, most people really mean "implementation defined" when they say something is undefined (or they mean that it is undefined in the specification). You have possibly verified that those two statements do the same thing for your compiler and your options. They at least produce the same assembly. That doesn't mean that it will work the same for all compilers, or even all options on a single compiler.

Is it really that hard to put the ++ on a separate line? Would you rather have to track down a possibly very hard to find bug when the code gets compiled with a new compiler, different options, or a different version? Apparently, this works differently just going from g++ 4.0.1/Mac OS 10.5.8 and g++ 4.4.5/Ubuntu Linux since the code posted by the original poster gets a different result. This probably has to do with the newer compiler actually performing more optimization and evaluating where the result should go before computing the result.

Also, you should prefer pre-increment over post-increment when the specific behavior of post-increment (returning a temporary) is not necessary. The compiler often optimizes the unnecessary temporary out, but why give it the option? This makes it so you rarely use the post increment forms, since they are generally unnecessary when you use ++ or -- as separate statements.

If you don't believe me that you should not read the value of a variable twice in an expression where you also modify it, be aware that Stroustroup says exactly the same thing.

http://www2.research.att.com/~bs/bs_faq2.html#evaluation-order

What's the value of i++ + i++?

It's undefined. Basically, in C and C++, if you read a variable twice in an expression where you also write it, the result is undefined. Don't do that. Another example is:
v[i] = i++;
Related example:
f(v[i],i++);

[rocketboy9000]

Hmm. So what you are saying is that the behavior which I thought was part of the standard, was actually just true for some compilers? Well, I can accept that, although I think this oddity should have been corrected a long time ago. Funny how the new standards, both c99 and c++, add features on, but never redefine anything that was previously left to the implementation.

[jimc]

For something like v[i]=i++, adding requirements on evaluation order will remove the ability to use certain optimizations since the left hand side calculates the address where the result should go. Just don't embed the increment You Stroustroup gave some of the reasoning behind this. It is pretty easy to avoid such hazards, so I don't see it as too big of an issue.

[rocketboy9000]

Oh man, I just realized you can just do this:
*p++ |= b;