relative precedence of ?: and assignment

[Andrew Koenig]

It has been pointed out to me that various C++ books disagree about
the relative precedence of ?: and the assignment operators.

In order to satisfy myself about the matter once and for all,
I looked at the grammar in the C++ standard. The relative fragments
are as follows:

conditional-expression:
logical-or-expression
logical-or-expression ? expression : assignment-expression

assignment-expression:
conditional-expression
logical-or-expression assignment-operator assignment-expression
throw-expression

Ordinarily, this grammar is almost, but not quite, in a well-known
form that, were it adhered to exactly, would say that
conditional-expressions have higher precedence than
assignment-expressions.

However, there is one crucial difference from this form: The rightmost
token in the second line of "conditional-expression" is
"assignment-expression" rather than "conditional-expression".
This difference makes the grammar somewhat harder to understand in
terms of precedence.

However, if we take the definition of assignment-expression and
replace the use of conditional-expression by its alternatives, we get:

assignment-expression:
logical-or-expression
logical-or-expression ? expression : assignment-expression
logical-or-expression assignment-operator assignment-expression
throw-expression

which we can rewrite this way:

cond-or-asn-op:
assignment-operator
? expression :

assignment-expression:
logical-or-expression
logical-or-expression cond-or-asn-op assignment-expression
throw-expression

From this rewrite, it should be clear that the assignment and ?:
operators have the same precedence, and they are right-associative.

Am I missing anything? If not, I'd like to urge all authors and
teachers of C++ to describe the precedence of these operators this
way; I think it's much easier to understand than any alternatives I've
seen.

 

[Alexander Terekhov]

Am I missing anything?

Uhmm,

"The syntax specifies the precedence of operators in the evaluation
of an expression, which is the same as the order of the major
subclauses of this subclause, highest precedence first. Thus, for
example, the expressions allowed as the operands of the binary +
operator (6.5.6) are those expressions defined in 6.5.1 through
6.5.6. The exceptions are cast expressions (6.5.4) as operands of
unary operators (6.5.3), and an operand contained between any of
the following pairs of operators: grouping parentheses () (6.5.1),
subscripting brackets [] (6.5.2.1), function-call parentheses ()
(6.5.2.2), and the conditional operator ?: (6.5.15)."

regards,
alexander.

--
"Good job SUN -- you've soiled yourselves with the stink of the
new pariah. The enemy of your enemy in this case was not your
friend. I hope IBM buys your sorry assets out, because we're
done with you."
-- "teambpsi" @ slashdot

 

[Andrew Koenig]

Alexander> "The syntax specifies the precedence of operators in the
Alexander> evaluation of an expression, which is the same as the order
Alexander> of the major subclauses of this subclause, highest
Alexander> precedence first. Thus, for example, the expressions
Alexander> allowed as the operands of the binary + operator (6.5.6)
Alexander> are those expressions defined in 6.5.1 through 6.5.6. The
Alexander> exceptions are cast expressions (6.5.4) as operands of
Alexander> unary operators (6.5.3), and an operand contained between
Alexander> any of the following pairs of operators: grouping
Alexander> parentheses () (6.5.1), subscripting brackets [] (6.5.2.1),
Alexander> function-call parentheses () (6.5.2.2), and the conditional
Alexander> operator ?: (6.5.15)."

Regardless of what the descriptive material may say, it does not add
any additional constraints to the grammar. Putting it differently,
if the grammar requires an expression to be parsed in a particular
way, then that is the way it's parsed.

 

[Alexander Terekhov]

Alexander> "The syntax specifies the precedence of operators in the
Alexander> evaluation of an expression, which is the same as the order
Alexander> of the major subclauses of this subclause, highest
Alexander> precedence first. Thus, for example, the expressions
Alexander> allowed as the operands of the binary + operator (6.5.6)
Alexander> are those expressions defined in 6.5.1 through 6.5.6. The
Alexander> exceptions are cast expressions (6.5.4) as operands of
Alexander> unary operators (6.5.3), and an operand contained between
Alexander> any of the following pairs of operators: grouping
Alexander> parentheses () (6.5.1), subscripting brackets [] (6.5.2.1),
Alexander> function-call parentheses () (6.5.2.2), and the conditional
Alexander> operator ?: (6.5.15)."

Regardless of what the descriptive material may say, it does not add
any additional constraints to the grammar. Putting it differently,
if the grammar requires an expression to be parsed in a particular
way, then that is the way it's parsed.

You might want to take a look at *C* grammer. Or am I just missing
and/or misunderstanding something?

regards,
alexander.

 

[Pete Becker]

You might want to take a look at *C* grammer. Or am I just missing
and/or misunderstanding something?

C and C++ are different here. Deliberately.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

 

[Pete Becker]

Heck. Why there should be any difference with respect to "relative
precedence of ?: and assignment" in C and C++?????

Because we changed it.

a ? b : c = 3;

In C, b is unchanged, regardless of the value of a. In C++, depending on
the value of a, 3 is assigned to either b or c.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

 

[Alexander Terekhov]

Because we changed it.

Interesting. Very interesting. It seems that both Annex C and
http://david.tribble.com/text/cdiffs.htm know *nothing* about
that change. Oder?

regards,
alexander.

 

[Pete Becker]

Because we changed it.

Apparently we didn't. <g> There was a lengthy discussion of how to do
it, complete with ad hoc BNF on whiteboards. Looks like it didn't make
it into the standard.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

 

[Alexander Terekhov]

Pete Becker wrote:
[...]

Apparently we didn't. <g>

Thanks god. ;-)

There was a lengthy discussion of how to do
it, complete with ad hoc BNF on whiteboards. Looks like it didn't make
it into the standard.

<from my email archive>

"Official/legal" C may allow use of conditional expressions as
lvalues in the future, oder? I really want to have *the same*
rules in both C and C++ with respect to "relative precedence of
?: and assignment".

regards,
alexander.

 

[Andrew Koenig]

Alexander> "Official/legal" C may allow use of conditional expressions
Alexander> as lvalues in the future, oder? I really want to have *the
Alexander> same* rules in both C and C++ with respect to "relative
Alexander> precedence of ?: and assignment".

The question I am addressing is not what you or I want, but what the
C++ standard actually says.

 

[Ron Natalie]

Alexander> "The syntax specifies the precedence of operators in the
Alexander> evaluation of an expression, which is the same as the order
Alexander> of the major subclauses of this subclause, highest
Alexander> precedence first. Thus, for example, the expressions
Alexander> allowed as the operands of the binary + operator (6.5.6)
Alexander> are those expressions defined in 6.5.1 through 6.5.6. The
Alexander> exceptions are cast expressions (6.5.4) as operands of
Alexander> unary operators (6.5.3), and an operand contained between
Alexander> any of the following pairs of operators: grouping
Alexander> parentheses () (6.5.1), subscripting brackets [] (6.5.2.1),
Alexander> function-call parentheses () (6.5.2.2), and the conditional
Alexander> operator ?: (6.5.15)."

Regardless of what the descriptive material may say, it does not add
any additional constraints to the grammar. Putting it differently,
if the grammar requires an expression to be parsed in a particular
way, then that is the way it's parsed.

One thing people must realize is that the precedence ordering is noit
the same as the grammar. You can't strictly reflect the grammar in
this case with the table.