Re: can you do if((myptr) && (myptr->IsGreen()) without blowing up? <d82274f7-953f-4a9b-ba84-905555465521@c58g2000hsc.googlegroups.com> <g3glp3$43d$1@aioe.org> <CqR6k.166$bB3.6@newsfe02.lga> <d0aa2e33-6007-4622-82ce-fc882d542f52@e39g2000hsf.googlegroups.com> <dxV6k.10680$uE5.6552@flpi144.ffdc.sbc.com> <2C37k.2865$5x5.2086@read4.inet.fi>
Charles Bailey
> red floyd wrote:
>> Also, if operator&&() or operator||() is overloaded, there is also no
>> such guarantee.
>
> The standard guarantees operator priorities (even if the operators are
> overloaded) but it doesn't guarantee the order in which the terms are
> evaluated for overloaded operators? Why is that?
'Priorities' (or precedence) are a consequence of the grammer rules of
C++. It is quite right that overloading doesn't change these. (Indeed
it would be quite hard, as whether an overloaded operator is called can
only be determined after it is determined which parts of the
expression bind to the left and right operands of a given operator.
Logically this means that the grammar rules need to be fixed before
operator overloading resolution occurs.)
The reason that the order of evaluation of the operators && and || is
guaranteed is not so much that the order matters that much itself, but
more that the second operand is guaranteed not to be evaluated at all
unless required. This allows a lot of common "is_safe_to_test &&
do_test" idioms to be guaranteed to be valid.
> Why does it make sense to guarantee priorities even for overloaded
> operators, but not the same evaluation rules?
In my opinion, a reason that evaluation order is not guaranteed for
overloaded operators is that there is far less benefit, as both
operands have to be evaluated in any case. This is because operator
overloading is implemented via function calls. By the time the body of
the function call is reached, both operands must have been evaluated
as the parameters to the function must both be available and have
these values. The logic of an overloaded operator is free to use or
ignore either or both of its parameters. There is no reasonable way in
the language to determine this at the site of the function call (where
the overloaded operator is used).
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
Charles Bailey
my original post. ]
