* Buster:
That they do not affect the evaluation order of the expression the calls
appear in. The first one, going in, ensures that arguments are fully
evaluated when the function starts executing. The last one, going out,
ensures that the function result copying (if any) is complete before
e.g. a destructor is called for the function result.
Right... ;-)
I don't think it follows. To give you something to push against, I will
say that I am thinking of the chronological ordering of inspections,
modifications and sequence points, not some lexical ordering. Therefore,
no matter in what order the subexpressions of "x = f (x) + g (x)" are
evaluated, the eventual evaluation of "f (x)" involves two sequence
points (sorry, three: i didn't mention the one at the end of "x += 7;"
which is itself a full expression), as does the evaluation of "g (x)",
and so those six sequence points occur, (at unspecified points) in time,
during the evaluation of the full expression.
I agree that they are executed in sequence (chronological ordering) _for
the sequence they apply to_, that's the point of having them.
What you have with f(x)+g(x) is however a hierarchy, not a linear
sequence.
The sequence points for the sequence of events in calling f are executed
in sequence. Likewise those for g. But the compiler is free to reorder
the top expression as g()+f(), because there's no sequence point there.
Sorry, you've lost me. Are you saying I've confused the issues of
sequence points and unspecified order of evaluation? Because I don't
think I have. f (x) must be evaluated 'all at once', and so must g (x).
Well I haven't said, but for what I'm thinking about what you might be
thinking (ha, philosophy enters clc++!), I think you may have needlessly
_differentiated_ between the concepts of sequence points and defined
evaluation order (sequence points are there to define the order),
and based on your comment about non-interference I think there's at
least a 40% dependent chance that you might then be thinking about
parallellism of some sort, which if you are would probably (75%
dependent chance?) stem from a need to make sense of the concept of
sequence point isolated from evaluation order: "it must mean something".
[snip]
But the standard says (right out loud) that it _is_ undefined behaviour.
That's what the latter two sentence of 5/4 say. If "i = ++i + 1;"
doesn't invoke undefined behaviour in virtue of those sentences, then
what does?
Yes, that is an issue, isn't it?
I'm more and more thinking it might be a defect.
Because _apparently_ the Holy Standard is inconsistent here.
Hold on, I might have just come up with a killer point. Look again at
the first commented code example after 5.4:
i = v [i++]; // the behaviour is unspecified
(i) There is no order-of-evaluation problem here (do you agree?).
On the surface yes but I think that's most likely where the problem lies
if there is no defect in this part of the standard.
(ii) If v is an std::vector (for instance), then [] is a real function
call. If I'm right about the relevance of sequence points in
functions to the evaluation of the calling expression, then it follows
that there is no problem whatsoever, and the behaviour is defined and
the result is specified. So (if I'm right) we have to assume [] is the
builtin subscript operator: that v and i are a pointer (or an array) and
an integer (but not necessarily in that order).
Right.
(Getting a headache?)
Nope.
(iii) Making that assumption, the only remaining problem is the lack of
a sequence point between the two modifications of i. (Huh? HUH?)
Yes, and there are two things to be said about that. (i) It doesn't
support either of our views. And (ii) it indicates to me that this part
of the standard was written to use a minimum of words, and so ended up
with an overly general definition of "unspecified" (or "undefined", as
the case _might_ be ;-) ) -- the example simply reflects that.
Details of (ii): it should IMO have described the evaluation tree of an
expression and and placed sequence points _inside_ each node, start and
end of evaluation of that node.
I.e., it should IMO have explicitly discussed expression hierarchies.
(iv) Therefore either the behaviour is undefined (I maintain it is),
or the result is specified. In either case the comment is wrong. What
do you think?
I think you're onto something, but you forgot that perhaps all those
mentions of "unspecified" may be right and the single mention of
"undefined" might be wrong -- or simply not sufficiently qualified.
Note that the comment does not say "the result is unspecified", which
would be very clear.
It's clear as it is (on its own, not considering the earlier text)
because "unspecified behavior" is _defined_ by §1 of the standard, I
think it was clause 13, as applying to the result.
BTW, I hope you're enjoying our little discussion.
Yep. ;-)
