James Kuyper wrote:
> I was under the impression that operator overloads [in C++] bypass the
> normal grammar rules. I couldn't find an explicit statement to that
> effect.

And you won't.  The grammar/syntax for operators, which includes
their relative precedence, is not affected by anything the user
can define, specifically operator overloading.  For example, no
matter what type of object Type::operator&&() returns, its
precedence remains the same relative to the other operators.
It would complicate parsers immensely to allow operator overloading
to affect their relative binding, and would probably cause many
cases for ambiguity.

<digress>
What I find irritating in C++ is that assignment operators are
allowed to return lvalues; this is what happens when such operators
are applied to primitive types (like 'int').  C is better in this
regard; 'c = a', by any reasonable logic, should not result in an
lvalue.
</digress>

-- David R. Tribble, dtribble@technologist.com --



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <366DC58D.6EC9D117@wizard.net>...
>I was under the impression that operator overloads bypass the normal
>grammar rules.

The grammar rules still apply.  '/' must still have two arguments, is left
associative, and has a higher precedence than '='.  So
   a = b / c / d
is evaluated as
   a = ((b / c) / d)
even when some of the operators are user-defined.

>I couldn't find an explicit statement to that effect. The
>best I could do was in Section 13.3.1.2, p1: "If no operand of an
>operator in an expression has a type that is a class or an enumeration,
>the operator is assumed to be a built-in operator and interpreted
>according to clause 5."

In section 5, p2: "Overloaded operators obey [these] rules for syntax ...
operand type, lvalue and evaluation order ... are replaced by the rule for
function call."

So
  a || b
when not built in has the same precedence as the built in || (precedence is
built into the grammar's syntax).  However it is evaluated as a function
call meaning both a and b are evaluated in an unspecified order, and there
are sequence points before and after the call.

>This seems to imply that clause 5 doesn't apply
>when one of the operands is a class or enumeration, but it doesn't
>explicitly say so.

5p2 kicks in when a user-defined overload is used for evaluation.  That can
only happen when at least one of the arguments is a struct or enum, but
doesn't necessarily happen.  C++ structs and enums still use the built in
operators by default.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <366CBCD0.51F9BC79@wizard.net>...
>I also noticed that C++ defines assignement-expression a bit differently
>than C9X:
>
>    assignment-expression:
>        conditional-expression
>        logical-or-expression assignment-operator assignment-expression
> throw-expression
>
>C9x has unary-expression rather than logical-or-expression.
>Why does C++ allow a logical-or-expression on the lhs? In the absence of
>operator overloads, a logical-or-expression that isn't also an
>pm-expression can't be an lvalue.


But in C++ logical-or may be overloaded to return an l-value.  Also
assignment operators may be overloaded to not require an l-value on the lhs.
So in C++
  a || b = c;
might make sense.  Having that expression mean (a||b) = c; is at least
consistent with what someone would expect from C's operator precedence.

I don't recall ever seeing a non-toy use for this, although having a||b
return an l-value is not uncommon in C++.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote in message <74jr2i$g66$1@uuneo.neosoft.com>...
>But in C++ logical-or may be overloaded to return an l-value.  Also
>assignment operators may be overloaded to not require an l-value on the
lhs.
>So in C++
>  a || b = c;
>might make sense.  Having that expression mean (a||b) = c; is at least
>consistent with what someone would expect from C's operator precedence.
>
>I don't recall ever seeing a non-toy use for this, although having a||b
>return an l-value is not uncommon in C++.


Just a thought of a non-toy use: what about a and b being threads that are
about to run concurrently via "||" and c is a stream or some producer that
feeds both with the same data. The constrction would make sense in a
fault-tolerant system.

Andrei




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:

> James Kuyper wrote in message <366CBCD0.51F9BC79@wizard.net>...
> >I also noticed that C++ defines assignement-expression a bit differently
> >than C9X:
> >
> >    assignment-expression:
> >        conditional-expression
> >        logical-or-expression assignment-operator assignment-expression
> > throw-expression
> >
> >C9x has unary-expression rather than logical-or-expression.
> >Why does C++ allow a logical-or-expression on the lhs? In the absence of
> >operator overloads, a logical-or-expression that isn't also an
> >pm-expression can't be an lvalue.
>
> But in C++ logical-or may be overloaded to return an l-value.  Also
> assignment operators may be overloaded to not require an l-value on the lhs.
> So in C++
>   a || b = c;
> might make sense.  Having that expression mean (a||b) = c; is at least
> consistent with what someone would expect from C's operator precedence.
>
> I don't recall ever seeing a non-toy use for this, although having a||b
> return an l-value is not uncommon in C++.

I was under the impression that operator overloads bypass the normal
grammar rules. I couldn't find an explicit statement to that effect. The
best I could do was in Section 13.3.1.2, p1: "If no operand of an
operator in an expression has a type that is a class or an enumeration,
the operator is assumed to be a built-in operator and interpreted
according to clause 5." This seems to imply that clause 5 doesn't apply
when one of the operands is a class or enumeration, but it doesn't
explicitly say so. I suspect that the relevant section (if I knew where
it was) gives a less broadly defined exemption than that.

If I'm right about that, then the grammar rule I quoted applies only to
the case where the logical-or-expression can't be an lvalue (unless it
is also a pm-expression).



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:
>
> Larry Weiss wrote in message
> <27E2AC4E0443B344.BE0EDBE49F80FC4C.E2001F98416BFA67@library-proxy.airnews.ne
> t>...
> >Douglas A. Gwyn wrote:
> >> Larry Weiss wrote:
> >> > [ a ? b : c = d    should mean a ? b : (c = d) ]
> >> > Is it too late to do that in C9X ?
> >>
> >> It was always too late for that.
> >
> >Why?  I thought Lawrence Kirby's idea was compelling.
> >What is the downside?
>
> It would increase compatibility with C++ where the grammar reads
>
>   logical-or-expression ? expression : assignment-expression

That's a somewhat nasty incompatibility!

I also noticed that C++ defines assignement-expression a bit differently
than C9X:

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

C9x has unary-expression rather than logical-or-expression.
Why does C++ allow a logical-or-expression on the lhs? In the absence of
operator overloads, a logical-or-expression that isn't also an
pm-expression can't be an lvalue.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]