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?

 
 
Angus
Guest
Posts: n/a
 
      06-20-2008
If I need to check if a pointer is valid I usually do a if(ptr) check
first.

But I have seen code such as this:

if((myptr) && (myptr->IsGreen())

Is this valid?

Is it because evaluation is from left to right so that the if(ptr) bit
is evaluated first. Then only if pointer is valid is right function
called?
 
Reply With Quote
 
 
 
 
peter koch
Guest
Posts: n/a
 
      06-20-2008
On 20 Jun., 18:20, Angus <(E-Mail Removed)> wrote:
> If I need to check if a pointer is valid I usually do a if(ptr) check
> first.
>
> But I have seen code such as this:
>
> if((myptr) && (myptr->IsGreen())
>
> Is this valid?


Yes, this is guaranteed to work.
>
> Is it because evaluation is from left to right so that the if(ptr) bit
> is evaluated first. *Then only if pointer is valid is right function
> called?


This is what is required in the standard, and all compilers adhere to
this requirement that dates back to C.

I would avoid the pointers and clarify by writing: if (myptr != 0 &&
myptr->IsGreen()), but this is a personal choice.

/Peter
 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      06-20-2008
Angus wrote:

> If I need to check if a pointer is valid I usually do a if(ptr) check
> first.
>
> But I have seen code such as this:
>
> if((myptr) && (myptr->IsGreen())
>
> Is this valid?


Yes.

> Is it because evaluation is from left to right so that the if(ptr) bit
> is evaluated first. Then only if pointer is valid is right function
> called?


The formal reason is the guarantee in [5.14/1]:

The && operator groups left-to-right. The operands are both implicitly
converted to type bool (clause 4). The result is true if both operands are
true and false otherwise. Unlike &, && guarantees left-to-right
evaluation: the second operand is not evaluated if the first operand is
false.


Best

Kai-Uwe Bux
 
Reply With Quote
 
Jim Langston
Guest
Posts: n/a
 
      06-20-2008
"Kai-Uwe Bux" <(E-Mail Removed)> wrote in message
news:g3glp3$43d$(E-Mail Removed)...
> Angus wrote:
>
>> If I need to check if a pointer is valid I usually do a if(ptr) check
>> first.
>>
>> But I have seen code such as this:
>>
>> if((myptr) && (myptr->IsGreen())
>>
>> Is this valid?

>
> Yes.
>
>> Is it because evaluation is from left to right so that the if(ptr) bit
>> is evaluated first. Then only if pointer is valid is right function
>> called?

>
> The formal reason is the guarantee in [5.14/1]:
>
> The && operator groups left-to-right. The operands are both implicitly
> converted to type bool (clause 4). The result is true if both operands
> are
> true and false otherwise. Unlike &, && guarantees left-to-right
> evaluation: the second operand is not evaluated if the first operand is
> false.


As a note, this is sometimes refered to as "short circuiting". It will also
work with ||
if ( cond1 || cond2 )

cond2 will only be evaluated if cond1 is false.


 
Reply With Quote
 
gw7rib@aol.com
Guest
Posts: n/a
 
      06-20-2008
On 20 Jun, 18:04, "Jim Langston" <(E-Mail Removed)> wrote:
> "Kai-Uwe Bux" <(E-Mail Removed)> wrote in message
>
> news:g3glp3$43d$(E-Mail Removed)...
> > Angus wrote:

>
> >> If I need to check if a pointer is valid I usually do a if(ptr) check
> >> first.

>
> >> But I have seen code such as this:

>
> >> if((myptr) && (myptr->IsGreen())

>
> >> Is this valid?

>
> > Yes.

>
> >> Is it because evaluation is from left to right so that the if(ptr) bit
> >> is evaluated first. *Then only if pointer is valid is right function
> >> called?

>
> > The formal reason is the guarantee in [5.14/1]:

>
> > *The && operator groups left-to-right. The operands are both implicitly
> > *converted to type bool (clause 4). The result is true if both operands
> > are
> > *true and false otherwise. Unlike &, && guarantees left-to-right
> > *evaluation: the second operand is not evaluated if the first operand is
> > *false.

>
> As a note, this is sometimes refered to as "short circuiting". *It will also
> work with ||
> if ( cond1 || cond2 )
>
> cond2 will only be evaluated if cond1 is false.


Note however that this is a special feature of the operators && and
||. If you do something like:

x = a() + b();

there is no guarantee which of a and b will be called first.
 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      06-20-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On 20 Jun, 18:04, "Jim Langston" <(E-Mail Removed)> wrote:
>> "Kai-Uwe Bux" <(E-Mail Removed)> wrote in message
>>
>> news:g3glp3$43d$(E-Mail Removed)...
>>> Angus wrote:
>>>> If I need to check if a pointer is valid I usually do a if(ptr) check
>>>> first.
>>>> But I have seen code such as this:
>>>> if((myptr) && (myptr->IsGreen())
>>>> Is this valid?
>>> Yes.
>>>> Is it because evaluation is from left to right so that the if(ptr) bit
>>>> is evaluated first. Then only if pointer is valid is right function
>>>> called?
>>> The formal reason is the guarantee in [5.14/1]:
>>> The && operator groups left-to-right. The operands are both implicitly
>>> converted to type bool (clause 4). The result is true if both operands
>>> are
>>> true and false otherwise. Unlike &, && guarantees left-to-right
>>> evaluation: the second operand is not evaluated if the first operand is
>>> false.

>> As a note, this is sometimes refered to as "short circuiting". It will also
>> work with ||
>> if ( cond1 || cond2 )
>>
>> cond2 will only be evaluated if cond1 is false.

>
> Note however that this is a special feature of the operators && and
> ||. If you do something like:
>
> x = a() + b();
>
> there is no guarantee which of a and b will be called first.


Also, if operator&&() or operator||() is overloaded, there is also no
such guarantee.
 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      06-20-2008
red floyd wrote:

> Also, if operator&&() or operator||() is overloaded, there is also no
> such guarantee.


Only criminals and madmen implement them otherwise.
 
Reply With Quote
 
Greg Herlihy
Guest
Posts: n/a
 
      06-21-2008
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.


But there is no way 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
 
Reply With Quote
 
Greg Herlihy
Guest
Posts: n/a
 
      06-21-2008
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

 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      06-21-2008
peter koch wrote:
>> if((myptr) && (myptr->IsGreen())
>>
>> Is this valid?

>
> Yes, this is guaranteed to work.


Nitpicking, but it's guaranteed to work only if myptr actually points
to an object of the proper type. If it points to garbage (which could be
achieved, for example, through reinterpret_cast), obviously UB will
happen. But yeah, this is just nitpicking.
 
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