expression and evaluation order and precedence rules

[Richard Heathfield]

Peter Nilsson said:

The order of sub-expressions is unspecified, except for ||, &&
and ?: operators. As you point out yourself, there is an implied
ordering of the + operations from the associativity.

I didn't point out any such thing. The associativity determines which
operands are used with which operators. That isn't the same as implying
an order of evaluation. Any evaluation ordering that happens to fall
out of an expression syntax is purely a consequence of reality, and has
nothing to do with the rules of C.

The expression i + j + k++ is evaluated on the virtual machine
as (i + j) + k++, not as i + (j + k++). There is potentially
a real difference on some machines.

If the values are initially, say, these:

i = 1;
j = -1;
k = INT_MIN;

then there is a real difference in the abstract machine, too.

Given...

#define CONV (-'0')

...and assuming *p is a digit, consider...

n = *p + CONV + n * 10;

This is a correct form only because there is an implied
ordering of evaluation.

Why? Precedence looks perfectly adequate here.

 

[Peter Nilsson]

Peter Nilsson said:

Your statement is too strong. 6.5p3 says sub-expressions,
not expressions, for a reason IMO.

If the values are initially, say, these:

i = 1;
j = -1;
k = INT_MIN;

then there is a real difference in the abstract machine,
too.

I cannot understand your statement that the ordering of
evaluation does not have _anything_ to do with associativity
when you are acknowledging the very fact that there is an
implied ordering on the abstract machine based on
associativity.

Perhaps I'm deluding myself, but I put it to you that my
(shared) delusion has practical usefulness that your
literism denies.

I write...

n = n * 10 + (*p - '0');

....because I believe the additive operators in...

n = n * 10 + *p - '0';

....are evaluated left to right and render the latter
expression flawed.

If I _had_ to reject the concept of associativity giving
an order to evaluation in that expression, I doubt I'd
continue programming.

Similarly, I don't think of expressions in terms of C
grammar, I think of them in terms of precedence and
associativity tables. I do so because the latter is
equivalent but much easier to apply in practice.

 

[Chris Dollin]

*** somebody lost attributions - evil **

I think people are missing something.

Yes; I have no idea how your post relates to the context; you'll
have to unpack the relationship for me.

 

[Chris Dollin]

I don't remember the details of the post, and you neglected to
quote it. So I have no reply.

\begin{quote}
I think people are missing something. Read my earlier observation
on adding (a few minutes ago) first, and then consider A * B in a
machine with sizeof int == 2. We do need an 8*8 multiply, and
interior carries have to be saved and used.

We can form A * B via:
lsbA * lsbB + K*(lsbA * msbB + lsbB * msbA) + K*K*(msbA * msbB)

and there are better algorithms available. K is related to
CHARBIT. So design the 8*8 multiply (when CHARBIT == 8) and you
have it all.

It helps to have built all this before.
\end{quote}

I don't see how this relates to precedence vs order-of-evaluation.

 

[Chris Hills]

Your signature is in gross violation of Usenet conventions and basic
netiquette. Please change it.

Your post was also a gross violation of Usenet conventions and basic
Netiquette

You must use ONLY ASCII for this NG

 

[Kenneth Brody]

Oh? For example, with sizeof int == 2, the addition operation
could well be simplified to:
[... snip pseudo-assembly example ...]

and neither operand was pre-evaluated. This will work just fine on
simple cpus such as the PIC that have a single 1-byte arithmetic
register, the accumulator.

Assembly is off-topic in c.l.c. So is pseudo-assembly.
How (if at all) the implementation chooses to translate code to
machine-language is inherently non-portable and non-standard.

I don't believe it's OT when being used as an example of a valid
compilation output, especially when the discussion was about what
sort of results are valid. For example, some of the myriad
possible outputs for "foo(i++,i++)", or how "i=i++" could result
in a frozen computer.

Sometimes, the best way to describe a situation is to give some
[pseudo-]assembler code.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Mark McIntyre]

I don't believe it's OT when being used as an example of a valid
compilation output,

Don't waste your breath - NetNanny is a troll, probably a sockpuppet
for one of our resident ones.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan