boolian and for contingency

[Mike - EMAIL IGNORED]

I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

Thanks for your help.
Mike.

[Roland Pibinger]

On Sat, 08 Jul 2006 13:01:48 -0400, Mike - EMAIL IGNORED
<m_*************@yahoo.comwrote:

>I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

OK, it's called shortcut evaluation.

Best wishes,
Roland Pibinger

[Roland Pibinger]

On Sat, 08 Jul 2006 17:12:44 GMT, rp*****@yahoo.com (Roland Pibinger)
wrote:

>On Sat, 08 Jul 2006 13:01:48 -0400, Mike - EMAIL IGNORED
<m_*************@yahoo.comwrote:

>>I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

OK, it's called shortcut evaluation.

Ahem, reading your question again, 'proper sequence' means 'left to
right' and 'no others execute' means 'no further execute', right?

[Frederick Gotham]

Mike - EMAIL IGNORED posted:

I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

Your code is perfectly OK.

-----------
| 5.14 -- Logical AND operator
|
| (1) The && operator groups left-to-right. The operands are both
| implicitly converted to type bool.
| 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.
-----------

In accordance with operator associativity rules, your expression:

fun1() && fun2() && fun3()

is the same as writing:

( fun1() && fun2() ) && func3()
What is does is:

Call "fun1". If "fun1" evalutes to false, then stop; otherwise, go
ahead and call "fun2". If "fun2" evalutes to false, then stop; otherwise,
go ahead and call "fun3".

--

Frederick Gotham

[Stuart Golodetz]

"Mike - EMAIL IGNORED" <m_*************@yahoo.comwrote in message
news:pa****************************@yahoo.com...

>I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

Thanks for your help.
Mike.

It works fine because of short-circuit evaluation. Bear in mind, though,
that there's a trade-off between brevity and clarity in this case. The right
thing to do in cases like this depends on subtleties like whether or not
your code is likely to be maintained by someone else (at some indefinite
point in the future), who may or may not find it easy to understand what
you're doing. Actually, a greater danger is that they'll understand what
you're doing but not be sure whether or not it was intentional. I'd suggest
commenting it to make it clear what was intended. Even a simple "// Note:
The reliance on short-circuit evaluation is intentional." would do the trick
:)

Cheers,
Stu

[Jerry Coffin]

In article <YO*******************@news.indigo.ie>, fg*******@SPAM.com
says...

[ ... ]

In accordance with operator associativity rules, your expression:

fun1() && fun2() && fun3()

is the same as writing:

( fun1() && fun2() ) && func3()
What is does is:

Call "fun1". If "fun1" evalutes to false, then stop; otherwise, go
ahead and call "fun2". If "fun2" evalutes to false, then stop; otherwise,
go ahead and call "fun3".

Associativity doesn't really have much to do with anything here.
What's relevant is that fact that the '&&' operator establishes a
sequence point, so its left operand is evaluated, then if and only if
its left operand evaluates to 'true' its right operand is evaluated.

Attempting to think of this in terms of associativity leads to
problems. For example, addition is also left associative, so:

x + y + z;

is equivalent to:

(x + y) + z;

The difference is that in this case there's no sequence point during
the evaluation, which means it's entirely possible for z to be
evaluated before x or y. Consider, for example, if x, y and z were
all instances of a rather odd proxy type that lets us see the order
in which the variables are evaluated:

#include <iostream>

class proxy {
char name_;
int value_;
public:
proxy(char name, int value) : name_(name), value_(value) {}

operator int() { std::cout << name; return value; }
};

int main() {
proxy x('x', 1);
proxy y('y', 2);
proxy z('z', 3);

int a = x + y + z;
return 0;
}

Now, even though this is evaluated as '(x+y)+z', the output of the
program is _not_ guaranteed to be 'xyz' -- it could perfectly
legitimately be any of the six possible permutations of the three
letters (e.g. 'zyx').

That's not to say that these are all equally likely -- in fact, I'd
guess most compilers will actually produce 'xyz' more often than not.
It's hard to imagine why a compiler would produce 'yxz' (for one
example) but that's more or less beside the point -- if there was a
reason to do so (even just that the compiler author was feeling
perverse) it would be perfectly legitimate to do so.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <MP***********************@news.sunsite.dk>,
jc*****@taeus.com says...

[ ... ]

operator int() { std::cout << name; return value; }

Oops -- that should, of course, be:

operator int() { std::cout << name_; return value_; }

Sorry 'bout that.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Mike - EMAIL IGNORED]

On Sat, 08 Jul 2006 17:17:32 +0000, Roland Pibinger wrote:

On Sat, 08 Jul 2006 17:12:44 GMT, rp*****@yahoo.com (Roland Pibinger)
wrote:

>>On Sat, 08 Jul 2006 13:01:48 -0400, Mike - EMAIL IGNORED
<m_*************@yahoo.comwrote:

>>>I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

OK, it's called shortcut evaluation.

Ahem, reading your question again, 'proper sequence' means 'left to
right' and 'no others execute' means 'no further execute', right?

Correct.

[Frederick Gotham]

Jerry Coffin posted:

Associativity doesn't really have much to do with anything here.

I did some testing just there and was surprised at the results. It seems
that parentheses have no effect on the && operator.

I expected the following code to print:

Func2 called. Returns false.
Func1 called. Returns false.
#include <iostream>
using std::cout;

template<bool exprbool Func1();

template<bool Func1<true>()
{
cout << "Func1 called. Returns true.\n";
return true;
}

template<bool Func1<false>()
{
cout << "Func1 called. Returns false.\n";
return false;
}

template<bool exprbool Func2();
template<bool Func2<true>()
{
cout << "Func2 called. Returns true.\n";
return true;
}

template<bool Func2<false>()
{
cout << "Func2 called. Returns false.\n";
return false;
}

template<bool exprbool Func3();
template<bool Func3<true>()
{
cout << "Func3 called. Returns true.\n";
return true;
}

template<bool Func3<false>()
{
cout << "Func3 called. Returns false.\n";
return false;
}

int main()
{
Func1<false>() && ( Func2<false>() && Func3<false>() );
}

--

Frederick Gotham

[jbannon]

Frederick Gotham wrote:

Jerry Coffin posted:

Associativity doesn't really have much to do with anything here.

I did some testing just there and was surprised at the results. It seems
that parentheses have no effect on the && operator.

I expected the following code to print:

Func2 called. Returns false.
Func1 called. Returns false.

<SNIP>

Nope, it will print "Func1 called. Returns false" because && guarantees
left-to-right evaluation order. In this case, the expression is
equivalent to E1 && E2 in which case E1 will always be evaluated first.

[Old Wolf]

Frederick Gotham wrote:

It seems that parentheses have no effect on the && operator.

I expected the following code to print:

Func2 called. Returns false.
Func1 called. Returns false.

In the code

X && Y

X evaluates first, regardless of whether Y contains parentheses.

[Howard]

"Stuart Golodetz" <sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote in message
news:O-********************@pipex.net...

"Mike - EMAIL IGNORED" <m_*************@yahoo.comwrote in message
news:pa****************************@yahoo.com...

>>I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

Thanks for your help.
Mike.

It works fine because of short-circuit evaluation. Bear in mind, though,
that there's a trade-off between brevity and clarity in this case. The
right thing to do in cases like this depends on subtleties like whether or
not your code is likely to be maintained by someone else (at some
indefinite point in the future), who may or may not find it easy to
understand what you're doing. Actually, a greater danger is that they'll
understand what you're doing but not be sure whether or not it was
intentional. I'd suggest commenting it to make it clear what was intended.
Even a simple "// Note: The reliance on short-circuit evaluation is
intentional." would do the trick :)

Cheers,
Stu

Even more clear would be:

if (fun1())
if (fun2())
if (fun3())
...

-Howard

[Victor Bazarov]

Howard wrote:

"Stuart Golodetz" <sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote in
message news:O-********************@pipex.net...

>"Mike - EMAIL IGNORED" <m_*************@yahoo.comwrote in message
news:pa****************************@yahoo.com.. .

>>I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

Thanks for your help.
Mike.

It works fine because of short-circuit evaluation. Bear in mind,
though, that there's a trade-off between brevity and clarity in this
case. The right thing to do in cases like this depends on subtleties
like whether or not your code is likely to be maintained by someone
else (at some indefinite point in the future), who may or may not
find it easy to understand what you're doing. Actually, a greater
danger is that they'll understand what you're doing but not be sure
whether or not it was intentional. I'd suggest commenting it to make
it clear what was intended. Even a simple "// Note: The reliance on
short-circuit evaluation is intentional." would do the trick :)

Cheers,
Stu

Even more clear would be:

if (fun1())
if (fun2())
if (fun3())
...

Nit pick: if you wanted the properly equivalent code, it had to be

if (fun1())
if (fun2())
fun3();

(there is no "..." in the original code, there is a semicolon after
the 'func3()')

And (you may flame me for that) when I see such two 'if's, I'll
*always* rewrite them as

if (fun1() && fun2())
fun3();

if I am maintaining that code.

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

[Howard]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:e8**********@news.datemas.de...

Howard wrote:

>"Stuart Golodetz" <sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote in
message news:O-********************@pipex.net...

>>"Mike - EMAIL IGNORED" <m_*************@yahoo.comwrote in message
news:pa****************************@yahoo.com. ..
I have three functions, each of which returns bool.
They must execute in proper sequence. If any returns
false, no others execute. So I write:

...
fun1() && fun2() && fun3();
...

OK?

Thanks for your help.
Mike.

It works fine because of short-circuit evaluation. Bear in mind,
though, that there's a trade-off between brevity and clarity in this
case. The right thing to do in cases like this depends on subtleties
like whether or not your code is likely to be maintained by someone
else (at some indefinite point in the future), who may or may not
find it easy to understand what you're doing. Actually, a greater
danger is that they'll understand what you're doing but not be sure
whether or not it was intentional. I'd suggest commenting it to make
it clear what was intended. Even a simple "// Note: The reliance on
short-circuit evaluation is intentional." would do the trick :)

Cheers,
Stu

Even more clear would be:

if (fun1())
if (fun2())
if (fun3())
...

Nit pick: if you wanted the properly equivalent code, it had to be

if (fun1())
if (fun2())
fun3();

(there is no "..." in the original code, there is a semicolon after
the 'func3()')

I see. I'd thought the OP was referring to a boolean expression he was
evaluating. Looks like he's ignoring the result, and simply using the
boolean short-circuit as a control mechanism. Very strange, and I'd never
do such a thing.

>
And (you may flame me for that) when I see such two 'if's, I'll
*always* rewrite them as

if (fun1() && fun2())
fun3();

if I am maintaining that code.

Flame! Flame!! Flame!!! :-)

(And at the risk of return flames...) I often end up taking apart such
statements (and making them separate if's) when trying to track down bugs,
because it's difficult to debug a boolean statement like that when the
individual elements are function calls. It's easy if you've got variables
whose values you can inspect, but not so easy to see what a function
returned, at least in some IDEs. But with function calls involved, I often
want to stop on a breakpoint when the call returns, to see exactly
what'sgoing on. (And stopping inside the functions is often a pain, since
they may get called umpteen times from other code, not just here.)

So, I leave intact such compound boolean statements when the elements are
variables, but break them apart when they're function calls. [donning fire
suit now]

-Howard

P.S., according to my boss: "Quit changing the code! If you're not changing
the functionality, leave it be!" I get that a lot. :-)

[Victor Bazarov]

Howard wrote:

[...]
P.S., according to my boss: "Quit changing the code! If you're not
changing the functionality, leave it be!" I get that a lot. :-)

Have your boss prove it to you that

if (blah)
if (blahbhal)
blahblahblah;

is *absolutely equivalent* (meaning from the optimizer point of view
as well) to

if (blah && blahblah)
blahblahblah;

then I'll shut up.

Then bring this up: if I insert "else" after it, what does it apply to?

if (blah)
if (blahbhal)
blahblahblah;
else
bloodyblah;

"I indented it correctly, man!" (Hey, I am not the one who writes
code like that!)

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

[Howard]

"Victor Bazarov" <v.********@comAcast.netwrote in message
news:e8**********@news.datemas.de...

Howard wrote:

>[...]
P.S., according to my boss: "Quit changing the code! If you're not
changing the functionality, leave it be!" I get that a lot. :-)

Have your boss prove it to you that

if (blah)
if (blahbhal)
blahblahblah;

is *absolutely equivalent* (meaning from the optimizer point of view
as well) to

if (blah && blahblah)
blahblahblah;

then I'll shut up.

Then bring this up: if I insert "else" after it, what does it apply to?

if (blah)
if (blahbhal)
blahblahblah;
else
bloodyblah;

"I indented it correctly, man!" (Hey, I am not the one who writes
code like that!)

In that case, I'd insert parentheses. And my boss would tell me to stop
changing the code. :-)

-Howard