On 11 mai, 17:05, Jerry Coffin <jcof...@[EMAIL PROTECTED]
> wrote:
> In article <68nqmmF2u7p5...@[EMAIL PROTECTED]
>, b...@[EMAIL PROTECTED]
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@[EMAIL PROTECTED]
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
|
