By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,778 Members | 2,015 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,778 IT Pros & Developers. It's quick & easy.

Order of functions in an IF

P: n/a
LSW
I've tried googling for the answer to this one, but haven't found anything.

In the following code snippet

BOOLEAN SomeValue;
if(SomeValue && SomeFunc())
DoSomething;

If SomeValue is False, will SomeFunc() be evaluated? Or will the
evaluation stop when a False is encountered in a boolean AND expression?

If it makes any difference, I'm currently using Turbo C++ 3.0 to develop
for an embedded system.

Thanks,
Jun 8 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
LSW wrote:
I've tried googling for the answer to this one, but haven't found anything.

In the following code snippet

BOOLEAN SomeValue;
if(SomeValue && SomeFunc())
DoSomething;

If SomeValue is False, will SomeFunc() be evaluated? Or will the
evaluation stop when a False is encountered in a boolean AND expression?
no, it won't be evaluated. The guaranteed order is left-to-right. For
the same reason A || B doesn't evaluates B if A is true.
If it makes any difference, I'm currently using Turbo C++ 3.0 to develop
for an embedded system.
I don't know if it makes any difference, it shouldn't. This is an old C
standard rule, so i think every compiler it's compliant on it.

Regards,

Zeppe
Jun 8 '07 #2

P: n/a
Zeppe wrote :
LSW wrote:
>I've tried googling for the answer to this one, but haven't found anything.

In the following code snippet

BOOLEAN SomeValue;
if(SomeValue && SomeFunc())
DoSomething;

If SomeValue is False, will SomeFunc() be evaluated? Or will the
evaluation stop when a False is encountered in a boolean AND expression?

no, it won't be evaluated. The guaranteed order is left-to-right. For the
same reason A || B doesn't evaluates B if A is true.
Note that that guarantee alone doesn't mean that SomeFunc() will not be
evaluated if SomeValue is false, but yes, the default logical or and
and expressions do short-circuit :)

However, if BOOLEAN or the return-value of SomeFunc() were some
user-defined type with an overloaded operator&&(), it will most
definitely *not* short-circuit, which is probably a good reason why you
should not want to overload those operators.

- Sylvester
Jun 8 '07 #3

P: n/a
Sylvester Hesp wrote:
Zeppe wrote :
>LSW wrote:
>>If SomeValue is False, will SomeFunc() be evaluated? Or will the
evaluation stop when a False is encountered in a boolean AND expression?

no, it won't be evaluated. The guaranteed order is left-to-right. For
the same reason A || B doesn't evaluates B if A is true.

Note that that guarantee alone doesn't mean that SomeFunc() will not be
evaluated if SomeValue is false, but yes, the default logical or and and
expressions do short-circuit :)
Sure. It was an additional information: if one argument is true, the
other is not evaluated AND the guaranteed order of evaluation is
left-to-right.
However, if BOOLEAN or the return-value of SomeFunc() were some
user-defined type with an overloaded operator&&(), it will most
definitely *not* short-circuit, which is probably a good reason why you
should not want to overload those operators.
Which is an interesting and not obvious collateral effect. I didn't ever
think about that, but given that if you overload the operator && you are
defining a function that will be called with the second argument of &&
as argument, and being a sequence point before the function call, there
is no way to redefine such an operator and retain the correct behaviour.

This is equivalent to say that A && B can not be viewed as
operator&&(A,B). This is a little bit shocking, frankly! :)

Regards,

Zeppe
Jun 8 '07 #4

P: n/a
Zeppe wrote:
Sylvester Hesp wrote:
>However, if BOOLEAN or the return-value of SomeFunc() were some
user-defined type with an overloaded operator&&(), it will most
definitely *not* short-circuit, which is probably a good reason why
you should not want to overload those operators.

Which is an interesting and not obvious collateral effect. I didn't
ever think about that, but given that if you overload the operator &&
you are defining a function that will be called with the second
argument of && as argument,
Actually, both the left-hand side and the right-hand side are the
operator's _arguments_. They are both evaluated before the function
is called. The order of evaluation is, of course, unspecified.
and being a sequence point before the
function call, there is no way to redefine such an operator and
retain the correct behaviour.
:-) Under "correct" you mean the "built-in" behaviour, of course.
The behaviour of the overloaded operator can only be "incorrect" if
the compiler screws up somehow.
This is equivalent to say that A && B can not be viewed as
operator&&(A,B). This is a little bit shocking, frankly! :)
They cannot be that only for non-overloaded variation of &&.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 8 '07 #5

P: n/a
Victor Bazarov wrote:
Zeppe wrote:
>Sylvester Hesp wrote:
>>However, if BOOLEAN or the return-value of SomeFunc() were some
user-defined type with an overloaded operator&&(), it will most
definitely *not* short-circuit, which is probably a good reason why
you should not want to overload those operators.
Which is an interesting and not obvious collateral effect. I didn't
ever think about that, but given that if you overload the operator &&
you are defining a function that will be called with the second
argument of && as argument,

Actually, both the left-hand side and the right-hand side are the
operator's _arguments_. They are both evaluated before the function
is called. The order of evaluation is, of course, unspecified.
it depends. If you redefine operator&& as a member argument of the class
A, A would be the member on which you apply the operator (which, of
course, is equivalent as considering it as the *this argument of a
binary operator).
>This is equivalent to say that A && B can not be viewed as
operator&&(A,B). This is a little bit shocking, frankly! :)

They cannot be that only for non-overloaded variation of &&.
Fair enough. But I always had this kind of naive idea that the behaviour
of all the built-in operators could be replicated by user defined
functions. :)

Regards,

Zeppe
Jun 8 '07 #6

P: n/a
On Jun 8, 4:59 pm, Zeppe
<zep_p@.remove.all.this.long.comment.yahoo.itwrote :
Victor Bazarov wrote:
Zeppe wrote:
>Sylvester Hesp wrote:
>>However, if BOOLEAN or the return-value of SomeFunc() were some
>>user-defined type with an overloaded operator&&(), it will most
>>definitely *not* short-circuit, which is probably a good reason why
>>you should not want to overload those operators.
>Which is an interesting and not obvious collateral effect. I didn't
>ever think about that, but given that if you overload the operator &&
>you are defining a function that will be called with the second
>argument of && as argument,
Actually, both the left-hand side and the right-hand side are the
operator's _arguments_. They are both evaluated before the function
is called. The order of evaluation is, of course, unspecified.
it depends. If you redefine operator&& as a member argument of the class
A, A would be the member on which you apply the operator (which, of
course, is equivalent as considering it as the *this argument of a
binary operator).
So? The order of evaluation is still not defined, and both must
be evaluated.
>This is equivalent to say that A && B can not be viewed as
>operator&&(A,B). This is a little bit shocking, frankly! :)
They cannot be that only for non-overloaded variation of &&.
Fair enough. But I always had this kind of naive idea that the behaviour
of all the built-in operators could be replicated by user defined
functions. :)
That's not true in a lot of cases. There's no way to make a
user defined operator require an lvalue, for example. If a, b
and c are build in types, for example, "(a+b) = c" is illegal;
if they are class types, however, it's not.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
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

Jun 8 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.