Re: The annotated annotated annotated C standard

In article <f9ca857e-289d-4484-b120-b15476676f12@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, spinoza1111 <spinoza1111@xxxxxxxxx> writes
Because precedence is not the same as order of evaluation. Something
that Algol recognised before C even existed. Indeed, IIRC, the idea that
they're the same is part of the heritage of the "infantile" (your word)
Fortran.

No, precedence is not the same as evaluation,

By god, He's got it!

But in the case of postincrement it's absolutely insane to split
precedence from order of evaluation

Oops, spoke too soon.

In p++ you can't be insisting sanely that you want to delay
incrementing until the smoke has cleared.

I want the increment done at the most convenient or efficient time. I don't care when that is.

>The most comprehensible and easy to explain
>behavior, which probably applies pre-standard

Actually, it doesn't.

>is that evaluation
>follows precedence and is left to right, as it still is in sensible
>languages.

Wrong to both.

You're entirely to ready to say "wrong" but you can't say why, can
you?

Well, it seems to be obvious to everyone else.

But since you seem desperate for clues ... firstly, pre-standard compilers did not all evaluate expressions in the same way (let alone left-to-right). This is why the Standard provides the leeway that it does. Where everyone did things the same way (e.g. how a for loop is executed) then that's what the Standard required. But since different compilers handled these cases in different ways, the Standard granted permission to continue so to do.

Of course, sensible programmers with experience of more than one compiler avoided such expressions anyway because they knew they didn't produce consistent results. So they weren't affected.

And, secondly, many languages don't have a "left to right" rule. Algol certainly doesn't - on the contrary, it grants even more freedom than C does.

And, thirdly, left-to-right is not necessarily the sensible thing to do. For example, in compiling a function call you may want the arguments on the stack with the first argument at the top. So the obvious order is right-to-left. When compiling "a + b * c", it may be more sensible to evaluate b, then c, then multiply, then evaluate a, then add.

>> Sequence points is compilers 101 stuff
>Then why are they not even covered in Aho, Sethi and Ullman's Dragon
>Book?
They are, just not with that name. A,S,&U understand the distinction
between the two concepts (see, for example, register graph colouring).
This is an optimization technique, not controlling the execution of
non-optimized code.

It's a related topic. Those who bother to study the issue know this.

And so why didn't you call it "register graph
coloring". I smell a cover up.

And every time I read one of your posts, I smell a pretentious fool who doesn't know he's a fool.

The right hand side has to be fully evaluated before the left hand
side is changed, and this includes side effects. Anything else is
madness, even in non-pathological code.

Not so. It depends very much on the architecture, and there are more architectures around than you have dreamed of.

>C sharp does it sensibly, returning 0, not 1.

If I were online, I'd be tempted to check the standard and see. I
suspect they actually say it's undefined.

It appears that my suspicion was wrong. I'm surprised, but I'm happy to accept that C sharp does it differently.

So, anything you can't master becomes a mystery.

I wish I knew how you got from what I said to that claim. Actually, I suspect that, when I find out your "logic", I'll wish I hadn't.

I thought you wrote the C Sharp standard.

No. I've never claimed that.

It appears to me that in the case of C, you may not have had the balls
to insist that the rhs of the assignment which is just an operator
with a side effect is fully evaluated including side effects because
some vendors didn't implement it this way.

Ignoring the gratuitous vulgar abuse, that's about the size of it.

[Though it wasn't me, because I wasn't on the Committee until after C89 was published. But I agree with their decision in this instance.]

How on earth would you implement post and pre increment by postponing
their side effects? Left to right? Would you ignore parentheses? How
about Monte Carlo or the Harlem shuffle?

How would you implement "i = i++ + i-- - --i * ++i"?

--
Clive D.W. Feather                       | Home: <cl...@xxxxxxxxxx>
Tel: +44 20 8495 6138 (work)             | Web:  <http://www.davros.org>
Fax: +44 870 051 9937                    | Work: <cl...@xxxxxxxxx>
Please reply to the Reply-To address, which is:  <cl...@xxxxxxxxxx>

Polite users of Usenet crop signatures rather than quoting them. Particularly corrupted versions.

--
Clive D.W. Feather | Home: <clive@xxxxxxxxxx>
Tel: +44 20 8495 6138 (work) | Web: <http://www.davros.org>
Fax: +44 870 051 9937 | Work: <clive@xxxxxxxxx>
Please reply to the Reply-To address, which is: <clive@xxxxxxxxxx>
.

Relevant Pages

  • Re: man 3 switch
    ... As C is an ISO standard, I sincerely doubt there would be any ... syntax and behaviour of the keywords between C compilers on any Unix-like ... of arithmetic operators of equal precedence in the same statement (in ... The languages themselves normally aren't. ...
    (Fedora)
  • Re: C/C++ Ambiguity in Order of Evaluation
    ... The order of evaluation of subexpressions is determined by the ... precedence and grouping of the operators. ... A reference manual that implements a language standard should be as ... settled in other manner that do not cause confusion. ...
    (comp.lang.c)
  • Re: C/C++ Ambiguity in Order of Evaluation
    ... The order of evaluation of subexpressions is determined by the ... precedence and grouping of the operators. ... A reference manual that implements a language standard should be as ... of any connection of precedence of operators with order of evaluation ...
    (comp.lang.c)
  • Re: The annotated annotated annotated C standard
    ... Because precedence is not the same as order of evaluation. ... same atomic operation, increment it, ... in your frigging standard. ...
    (comp.programming)
  • Re: C/C++ Ambiguity in Order of Evaluation
    ... The order of evaluation of subexpressions is determined by the ... precedence and grouping of the operators. ... A reference manual that implements a language standard should be as ... of any connection of precedence of operators with order of evaluation ...
    (comp.lang.c)