Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > can you do if((myptr) && (myptr->IsGreen()) without blowing up?

Reply
Thread Tools

can you do if((myptr) && (myptr->IsGreen()) without blowing up?

 
 
peter koch
Guest
Posts: n/a
 
      06-21-2008
On 21 Jun., 05:00, Greg Herlihy <(E-Mail Removed)> wrote:
> On Jun 20, 3:08 pm, Noah Roberts <(E-Mail Removed)> wrote:
>
> > red floyd wrote:
> > > Also, if operator&&() or operator||() is overloaded, there is also no
> > > such guarantee.

> > Only criminals and madmen implement them otherwise.

>
> You must mean that only criminals and madmen implement these overloads
> -at all-.
>
> Because there is no way for anyone to specify the order in which the
> operands will be
> evaluated when implementing an overloaded operator&&(), operator||()
> or (for that matter) operator,(). For this reason, overloading any
> one
> of these three operators is seldom a good idea.
>
> Greg


Right. But that does not exclude the rare occasions where overloading
is fine. For one example, you could imagine overloading those
operators when you implement fuzzy logic. In that case, you would of
course be aware that both operands would be overloaded.

/Peter
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      06-21-2008
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?

That is, if you do something like "a && b + c", where both operator&&
and operator+ have been overloaded for the used type, it's, AFAIK,
guaranteed that operator+ will be called with b and c as parameters and
then operator&& with a and the result of that operator+ call as
parameters. However, whether the result of a or b+c is evaluated first
is not guaranteed? Why?

Why does it make sense to guarantee priorities even for overloaded
operators, but not the same evaluation rules?
 
Reply With Quote
 
 
 
 
Yakov Gerlovin
Guest
Posts: n/a
 
      06-21-2008
> if((myptr) && (myptr->IsGreen())
>
> Is this valid?


Generally, it is valid. However, I have seen compiler options such as
"full evaluations of binary expressions". This option means that all
expressions are evaluated, even though the result is known without
calculating all of them.

My 2 cents
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      06-21-2008
Yakov Gerlovin wrote:
>> if((myptr) && (myptr->IsGreen())
>>
>> Is this valid?

>
> Generally, it is valid. However, I have seen compiler options such as
> "full evaluations of binary expressions". This option means that all
> expressions are evaluated, even though the result is known without
> calculating all of them.


I really can't understand the reason for a compiler to offer such an
option. Not only does it break the standard, it probably breaks a lot of
code, and potentially makes code very inefficient. It's also completely
useless because if at some point in your code you really need to
evaluate both expressions, you can do that explicitly:

bool ret1 = expression1();
bool ret2 = expression2();
if(ret1 && ret2) ...

which also makes it quite clearer that evaluating both expressions is
intended, instead of being a hidden feature of an obscure compiler option.

That kind of option just doesn't make any sense whatsoever.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      06-21-2008
On Jun 21, 11:12 am, Juha Nieminen <(E-Mail Removed)> wrote:
> 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?


> That is, if you do something like "a && b + c", where both
> operator&& and operator+ have been overloaded for the used
> type, it's, AFAIK, guaranteed that operator+ will be called
> with b and c as parameters and then operator&& with a and the
> result of that operator+ call as parameters. However, whether
> the result of a or b+c is evaluated first is not guaranteed?
> Why?


Because what is actually guaranteed is that the second operand
won't even be evaluated if the truth value of the expression can
be determined by the first. But there is no way to call a user
defined binary operator without first having evaluated both
operands.

> Why does it make sense to guarantee priorities even for
> overloaded operators, but not the same evaluation rules?


Because they would be impossible to specify: you would need to
call a function with two operands, but not have evaluated the
second under some undefined conditions (undefined, because
that's what the overload would define).

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      06-21-2008
On 21 Jun., 11:37, Yakov Gerlovin <(E-Mail Removed)> wrote:
> > if((myptr) && (myptr->IsGreen())

>
> > Is this valid?

>
> Generally, it is valid. However, I have seen compiler options such as
> "full evaluations of binary expressions". This option means that all
> expressions are evaluated, even though the result is known without
> calculating all of them.
>
> My 2 cents


I have not, but certainly using such an option makes the behaviour non-
compliant, and it also would break tons of code in existence. What
compiler are you talking about?
I have an understanding for other languages that prefer more freedom
in evaluating boolean expression - one obvious example is SQL. Also
Ada will normally guarantee evaluation of both sides. Special
operators are needed to avoid this (AND THEN resp. OR ELSE). In my
mind, this is the wrong default for a low-level language (and the
right one for a highlevel ditto).

/Peter
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      06-21-2008
James Kanze wrote:
> Because they would be impossible to specify: you would need to
> call a function with two operands, but not have evaluated the
> second under some undefined conditions (undefined, because
> that's what the overload would define).


Clearly C++ needs some form of lazy evaluation...
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      06-23-2008
Greg Herlihy wrote:
> On Jun 20, 3:08 pm, Noah Roberts <(E-Mail Removed)> wrote:
>> red floyd wrote:
>>> Also, if operator&&() or operator||() is overloaded, there is also no
>>> such guarantee.

>> Only criminals and madmen implement them otherwise.

>
> You must mean that only criminals and madmen implement these overloads
> -at all-.


No, I just didn't think about it clearly since I never do it.

I can imagine that you might want to, but I'd think twice about it any
time I might. Since you can't write it to have the same behavior, you
can't really call templates that use it. Probably better to explicitly
use some function call that you then override for basic types so you can
use your new templates with old types.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Response is not available in this context - page blowing rao ASP .Net 1 08-27-2004 10:55 PM
Purchasing Camera Experience...... Bad hair Day Rant - Blowing Off Steaml... BobS Digital Photography 2 08-21-2004 04:07 AM
Re: Deano explains that he's not bothered by his wife blowing hisfriends. =?iso-8859-1?Q?=B1?= Digital Photography 0 07-12-2004 07:57 AM
ASP net worker process blowing up !! Ashish ASP .Net 1 11-17-2003 05:18 PM
Blowing the doors to Palm - Java programming for Tungsten handhelds asj Java 138 09-01-2003 07:44 PM



Advertisments