relative precedence of ?: and assignment
Andrew Koenig
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.
--
Andrew Koenig, a...@acm.org
Alexander Terekhov
Andrew Koenig wrote: <about "teaching">
[...]
> 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> 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.
--
Andrew Koenig, a...@acm.org
Alexander Terekhov
You might want to take a look at *C* grammer. Or am I just missing
and/or misunderstanding something?
regards,
alexander.
--
"Freedom is a perceived necessity. Freedom of speech is NOT saying
whatever you want. The sooner as you realize that, the better your
life is going to be."
-- Victor Bazarov
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
Alexander Terekhov
Pete Becker wrote:
>
> Alexander Terekhov wrote:
> >
> > 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.
Heck. Why there should be any difference with respect to "relative
precedence of ?: and assignment" in C and C++????? In C (99), the
rightmost token in the second line of "conditional-expression" IS
"conditional-expression" rather than "assignment-expression".
regards,
alexander.
Pete Becker
>
> Pete Becker wrote:
> >
> > Alexander Terekhov wrote:
> > >
> > > 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.
>
> 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.
Alexander Terekhov
Pete Becker wrote:
>
> Alexander Terekhov wrote:
> >
> > Pete Becker wrote:
> > >
> > > Alexander Terekhov wrote:
> > > >
> > > > 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.
> >
> > Heck. Why there should be any difference with respect to "relative
> > precedence of ?: and assignment" in C and C++?????
>
> 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
>
> Alexander Terekhov wrote:
> >
> > Pete Becker wrote:
> > >
> > > Alexander Terekhov wrote:
> > > >
> > > > 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.
> >
> > Heck. Why there should be any difference with respect to "relative
> > precedence of ?: and assignment" in C and C++?????
>
> 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.
Alexander Terekhov
Pete Becker wrote:
[...]
> > > Heck. Why there should be any difference with respect to "relative
> > > precedence of ?: and assignment" in C and C++?????
> >
> > Because we changed it.
> >
>
> 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> 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.
--
Andrew Koenig, a...@acm.org
Alexander Terekhov
That's fine as long as the objective is to file a defect report if
yours->"official" interpretation won't match the ISO C rules. TIA.
regards,
alexander.
P.S. I just hate "off-band" conversations.
Ron Natalie
"Andrew Koenig" <a...@acm.org> wrote in message news:yu99r84v...@tinker.research.att.com...
the same as the grammar. You can't strictly reflect the grammar in
this case with the table.