*++p vs ++*p

[Francis Moreau]

Think of it like this: precedence just provides automatic insertion of
brackets.  For example, the relative precedence of + and * means that
a+b*c is equivalent to a+(b*c).

Now there's no way of inserting brackets in *++p to make the * go
with p, or in ++*p to make the ++ go with p, so precedence is irrelevant.

That's actually a good representation of precedence.

Thanks !

 

[Francis Moreau]

The only possible evaluation order for the above expression is

         op1  (opx (op3 obj) )

This order is dictated by the structure of the expression, not
by any precedence order amongst op1, opx and op3.

In fact, all unary prefix operators can be thought of having equal
precedence, the evaluation order is determined by the distance to the operand.

Yes actually thinking more about it, it's impossible for the spec
to introduce a new prefix operator with a different precedence than
the unary prefix operator group since it can't be expressed by the
grammar and precedence are actually given by the grammar.

Thanks !

 

[Francis Moreau]

[...]

The C standard doesn't use the concept of operator precedence. It uses
grammar productions, instead.

yes that was the point I was missing.

However, ith only a few exceptions, the
grammar can be explained using the concept of precedence

Now I really prefer thinking this concept with the language grammar.

Thanks for your explanations !

 

[Richard Bos]

Again, this is a troll, and not from me. The path originates in
eternal-september.org

It does, however, have a point. Numbers up to twenty are usually easier
to read, in a normal sentence, when written out.

Richard

 

[Ben Bacarisse]

The only possible evaluation order for the above expression is

op1 (opx (op3 obj) )

Personally I stress that it is parsed like that. The evaluation order
is strongly implied (there is a natural one -- inside out) but it
need not be adhered to. In fact C has an example: & and * cancel out
so that &*x is pared as &(*x) but evaluated as x.

This order is dictated by the structure of the expression, not
by any precedence order amongst op1, opx and op3.

I'd say "suggested" rather than "dictated".

In fact, all unary prefix operators can be thought of having equal
precedence, the evaluation order is determined by the distance to the operand.

Similarly, all unary postfix operators have equal precedence, and
the evaluation order is determined by the distance to the operand.

In C, unary postfix operators, as a group, have higher precedence than
unary prefix operators as a group.

So, for example, if op1, op2 and op3 are unary prefix operators, and
opx, opy and opz are unary postfix operators, then

op1 op2 op3 obj opx opy opz

is evaluated as:

op1 (op2 (op3 ( ( (obj opx) opy) opz) ) )

At the risk of confusing the OP, if you had taken his hypothetical
higher precedence prefix opx and mixed it in with your example like
this:

op1 op2 opx obj opy opz

then it would be parsed as:

op1 (op2 (((opx obj) opy) opz))

The point being that the precedence of unary operators only "kicks in"
when mixing pre- and postfix operators.

But, as you say, in C there are only two groups: all postfix operators
bind more tightly than all prefix operators.

 

[Ben Bacarisse]

Yes actually thinking more about it, it's impossible for the spec
to introduce a new prefix operator with a different precedence than
the unary prefix operator group since it can't be expressed by the
grammar and precedence are actually given by the grammar.

Not at all, though this is drifting far from C. Look at my other post
(in reply to Ike) and see if you think no grammar can express that
syntax.

 

[Kaz Kylheku]

So now let say the next spec introduce a new unary operator 'opx'
which has a higher precedence than all others unary operators.

how the following expression is evaluated ?

You mean how it is parsed! Associativity and precedence determine the parse.
Evaluation is semantics. In the design of a language, the semantics of
evaluation for a given syntax can be completely arbitrary, so that can be
discussed separately.

op1 opx op3 obj

If opx has a higher precedence it means that the parse is, perhaps, like this:

(op1 ((opx op3) obj))

I.e. the argument to opx is the operator op3.

I say ``perhaps'' because we don't know the phrase structure role of the ``opx
op3'' combination. The above example parse assumes that the compound ``opx
op3'' behaves as a unary operator. That is, (opx op3) is a prefix that applies
to obj, and then op1 applies to the whole thing.

So effectively, you have the individual operators opx and op3, and then the
combination of these two tokens which make a third operator of some kind.

This kind of agglutination of operators is typically expressed in the lexical
syntax, not in the phrase structure grammar. E.g. += isn't treated as two
tokens (at least not today; I seem to vaguely recall that may have been the
case in some early C compilers).

 

[Francis Moreau]

Not at all, though this is drifting far from C. Look at my other
post (in reply to Ike) and see if you think no grammar can express
that syntax.

I don't see how your other post:

Message-ID: <[email protected]>

answer to the initial qestion, sorry.

That was how "op3 opx op1 obj" is parsed knowing that opx has higher
precedence than other prefix unary operators.

 

[Ben Bacarisse]

I don't see how your other post:

Message-ID: <[email protected]>

answer to the initial qestion, sorry.

No it doesn't. I was only commenting on the text I quoted. Since I
happened to have posted a counter example to what it says, I referred
you to that post rather than repeating it again.

 

[Ralf Damaschke]

Ah I've been mistaken by this:

http://fr.wikibooks.org/wiki/Programmation_C/Opérateurs

where it looks like ++ precedence is higher than * one.

It's probably perfectly possible to use such a rule. However
there are some serious faulty views regarding other precedences:

IIUC the page states that "!" has a higher precedence than "++".
This is wrong. It would make the expression (given "unsigned u=0")
"!u++" invalid, which it isn't. Also a cast does not have a
higher precedence than the sizeof operator, otherwise
"sizeof(char)+1" would be 1 instead of 2.

-- Ralf

 

[Francis Moreau]

It's probably perfectly possible to use such a rule.

What do you mean by this ?

However
there are some serious faulty views regarding other precedences:

IIUC the page states that "!" has a higher precedence than "++".
This is wrong. It would make the expression (given "unsigned u=0")
"!u++" invalid, which it isn't. Also a cast does not have a
higher precedence than the sizeof operator, otherwise
"sizeof(char)+1" would be 1 instead of 2.

yes, this link is really confusing: note that how all unary operators
seem to have a different
precedence.

Also there's no difference between '++' postfix and prefix operator.

 

[Andrey Tarasevich]

In my understanding, this 2 expressions are equal since '++' operator
has a higher precedence than '*' operator.

But of course they aren't (I checked with a short test program).

So I'm missing something in the C spec about the evalution of
expressions.
...

Precedence comes into play only when there's a syntactic/semantical
ambiguity. That includes such major cases like:

1) binary operator vs. binary operator,
e.g. '2 + 2 * 2' means '2 + (2 * 2)'
2) prefix unary operator vs. postfix unary operator,
e.g. '*p++' means '(*p)++'
3) prefix unary operator vs. binary operator
e.g. '*p + 1' means '(*p) + 1'

and some other, more rare, situations.

In your example (two prefix unary operators) there's no ambiguity. The
inner operator (whatever that is) is applied to 'p', while the outer
operator (whatever that is) is applied to the result of the inner one.
Precedence doesn't matter at all in this case.

 

[Ralf Damaschke]

What do you mean by this ?

OK, the "++" operator serves as postfix as well as prefix operator.
When used as postfix operator it clearly has a higher precedence
than any of the "*" operators. When used as prefix operator (and
there are no ambiguities for distinguishing post or prefix use)
only other prefix operators could have influence. But for prefix
use these are already sorted out by position.

-- Ralf