Re: Unpredictable nature of increment operators
On 11 mai, 17:05, Jerry Coffin <jcof...@taeus.com> wrote:
In article <68nqmmF2u7p5...@mid.individual.net>, b...@gmb.dk says...
[ ... ]
1: Though it's open to some question. $1.9/8 says: "Once
the execution of a function begins, no expressions from
the calling function are evaluated until execution of the
called function has completed."
I'm interpreting evaluating the arguments to a function as
part of execution of the function. If you choose to
interpret it as a completely separate act that happens
before the function's execution, then you're right -- no
ordering is defined. At least in this case, it doesn't
make any real difference though -- the overall result is
undefined behavior either way.
I think your second interpretation is the correct one. It
means that ++i can be evalueated before or after calling f,
but not during.
You could _certainly_ be right. As I said, in this case it
doesn't really make much difference, since either one gives
undefined results.
I got curious and read through N2284, and found that the
wording has been changed to [intro.execution]/16:
Every evaluation in the calling function (including other
function calls) that is not otherwise specifically
sequenced before or after the execution of the body of
the called function is indeterminately sequenced with
respect to the execution of the called function.
This is apparently an attempt at clarifying the situation, but
doesn't seem (to me) to add much clarity.
This isn't so much an attempt at clarifying the situation, as at
making the text relevant in a multithreaded environment.
I'm pretty sure that there was a DR in C which made this clear;
the actual question was different (could the compiler interleaf
the execution of two functions), but the text in the
clarification made it clear that just about any reordering is
permitted before the actual function call and after the return.
(This is from memory, however; I have no idea how to go about
finding the actual DR, and it's quite possible that I'm basing
my opinion on discussions concerning the DR, and not only on the
formal answer to it.)
In particular, it specifically cites execution of the body of
the function in one place, but execution of the called
function in the other. It's not at all clear whether this is
just mildly sloppy wording, and the two are intended to be
synonymous, or whether it's completely intentional, and
intended to delineate between the two.
In general, I think that there is a fairly widespread consensus
that the way C describes sequence points, and the way they
establish an ordering, is far from optimal. The C committee
decided to not address the issue in the C99 revision, on the
grounds that while far from optimal, it was sufficient, and
there was no real indication that any of the proposed
alternatives were better (i.e. clearer). Unless you want to
specify ordering fully, as in Java, it's a difficult issue to
define precisely when to stop. The philosophy of sequence
points doesn't work at all in a multithreaded environment,
however, so the C++ committee is obliged to find something else.
Hopefully, clearer, but unless you define full ordering, it's
difficult to be really clear (and requiring full ordering in a
multithreaded environment has a number of additional
problems---even Java punts on this one, resulting in what would
be called in C++ "undefined behavior").
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34