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

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?

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

On 20 Jun., 18:20, Angus <anguscom...@gmail.com> 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

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

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

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

"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:g3glp3$43d$1@aioe.org...
> 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.

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

On 20 Jun, 18:04, "Jim Langston" <tazmas...@rocketmail.com> wrote:
> "Kai-Uwe Bux" <jkherci...@gmx.net> wrote in message
>
> news:g3glp3$43d$1@aioe.org...
> > 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.

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

gw7rib@aol.com wrote:
> On 20 Jun, 18:04, "Jim Langston" <tazmas...@rocketmail.com> wrote:
>> "Kai-Uwe Bux" <jkherci...@gmx.net> wrote in message
>>
>> news:g3glp3$43d$1@aioe.org...
>>> 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.

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

red floyd wrote:

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

Only criminals and madmen implement them otherwise.

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

On Jun 20, 3:08*pm, Noah Roberts <u...@example.net> 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

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

On Jun 20, 3:08 pm, Noah Roberts <u...@example.net> 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

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

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.