Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
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?
I'm trying to nail down the semantics. Here is the case where there
provably is no stomping. If this can be optimized away then the
language guarantee has to be formulated accordingly. Right now I
don't know what to expect from the code I wrote. Is it a good
substitute for duplicate or not?
The answer is very simple, and it is present in the book. I have also
repeated it here. Appending to an array may or may not terminate an
existing sharing relationship, and it never initiates a sharing
relationship. Assigning a larger length is equivalent to appending a
number of default-initialized values. There is nothing difficult here,
although convoluted examples can be created that compound "if"s in
complex interactions.
I get worried when the semantics of a very important and essential
primitive--the array--is hard to explain and comprehend.
We have a couple of dozens of other things to worry about. There are
deadlines and many other more important and more urgent things to work
on. The primitive is not important and not essential. It's a primitive,
and like all primitives, it can be used to create better abstractions.
UDP is a primitive protocol with few guarantees, but TCP is implemented
on top of it to provide the guarantees. Simple, efficient primitives are
a defensible choice.
Andrei
