Bartosz Milewski wrote:
Steven Schveighoffer Wrote:
As long as the spec says changing length may expand the array to hold enough
space, the optimizer can't, because the optimization would change the side
effects of the function. An optimizer should not change the outcome or side
effects of a function. It's not unheard of for an optimizer to eliminate
important operations that it thinks are invalid, but in that case, it's a
broken optimizer, I don't see why we would add this case.
This is all true for user-defined data types, but array is totally under
compiler's control. What optimizations are acceptable depends only on the
interpretation of the language spec. In particular the sequence
a.length -= 1;
a.length += 1;
as a whole does not result in stomping, so why would it be wrong to optimize it away? I claim it's perfectly legitimate.
Yes, but this gets into optimizing sequences of complex operations, so
the question is one of expectancy. What if I insert something there:
a.length -= 1;
writeln("Why oh why???");
a.length += 1;
After all people don't ordinarily expect C++ compilers to optimize away
a.resize(a.size() - 1);
a.resize(a.size() + 1);
Each function has some semantics and effects, and I don't know why we'd
want to get down the route that effects depend on the flow in which the
function gets called.
What is the example trying to accomplish?
Andrei
