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

[Angus]

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?

[peter koch]

On 20 Jun., 18:20, Angus <[e-mail]:

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

[Kai-Uwe Bux]

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

[Jim Langston]

"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:g3**********@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.

[gw7rib]

On 20 Jun, 18:04, "Jim Langston" <[e-mail]:

"Kai-Uwe Bux" <[e-mail] in message

news:g3**********@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 operandis
*false.

As a note, this is sometimes refered to as "short circuiting". *It willalso
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.

[red floyd]

gw****@aol.com wrote:

On 20 Jun, 18:04, "Jim Langston" <[e-mail]:

>"Kai-Uwe Bux" <[e-mail] in message

news:g3**********@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.

[Noah Roberts]

red floyd wrote:

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

Only criminals and madmen implement them otherwise.

[Juha Nieminen]

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.

[Yakov Gerlovin]

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

[Juha Nieminen]

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.

[peter koch]

On 21 Jun., 11:37, Yakov Gerlovin <[e-mail]:

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

[Juha Nieminen]

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... ;)

[Noah Roberts]

Greg Herlihy wrote:

On Jun 20, 3:08 pm, Noah Roberts <[e-mail]:

>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.