Logical And

[sam]

Please look at the code below
#include <stdio.h>

int expr(char str[], int i){
printf("%s \n",str);
return i;
}

int main()
{
if(expr("1st",1 ) || expr("2nd",0) && expr("3rd",1));
return 0;
}

output
-------
1st

As && has an higher precedence over ||
then it should call expr("2nd",0) or expr("3rd",0)
first then why it calls (expr("1st",1) first

Regards
Shiju

[Dan Pop]

In <bu**********@n ews.tudelft.nl> Sidney Cadot <si****@jigsaw. nl> writes:

Eric Sosman wrote:

Sidney Cadot wrote:

Mark A. Odell wrote:
"osmium" <r1********@com cast.net> wrote in

Why on earth would you ever evaluate b if a is true?

If this wasn't a rhetorical question, I /could/ think of an answer. For
example: short-circuit evaluation may, under some circumstances,
negatively impact the size and/or speed of generated assembly code
(e.g., by introducing pipeline stalls).

You're missing the point, I think.

Umm no, I don't think so. I was merely following my instincts, which
invariably make me answer seemingly rhetorical questions.

Short-circuit evaluation isn't about efficiency, but about correctness.
The || and && operators are *defined* to work this way;
an implementation that evaluated `b' when `a' was true
would not be an implementation of C.

According to the "as if" principle, a compiler is perfectly free to do
this given the right circumstances. And, in fact, it may just be the
clever thing to do.

But the point is that it can do it *only* when the program can't tell
the difference. Fortran programmers often wish they could do things
like:

if (a == 0 || b / a > 0) /* do something */ ;

The short circuiting feature of || and && is not an optimisation feature,
its purpose is to make the language easier to use. Without it, the
above statement would have to be rewritten as:

if (a == 0) /* do something */ ;
else if (b / a > 0) /* do it again */ ;

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:
[...]

The short circuiting feature of || and && is not an optimisation feature,
its purpose is to make the language easier to use.
above statement would have to be rewritten as:

I suspect it would be more accurate to say that it's not *just* an
optimization feature. Efficiency may also have been a concern when
the feature was first designed (probably in one of C's ancestors).

It's a happy coincidence that ease of use and efficiency (on the
hardware of the time) both led to the same design decision.

I haven't looked at the relevant historical documents lately, so I'm
only guessing here.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Dan Pop]

In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:

Da*****@cern.c h (Dan Pop) writes:
[...]

The short circuiting feature of || and && is not an optimisation feature,
its purpose is to make the language easier to use.
above statement would have to be rewritten as:

I suspect it would be more accurate to say that it's not *just* an
optimization feature. Efficiency may also have been a concern when
the feature was first designed (probably in one of C's ancestors).

It's a happy coincidence that ease of use and efficiency (on the
hardware of the time) both led to the same design decision.

I haven't looked at the relevant historical documents lately, so I'm
only guessing here.

I was using the *present* tense, so whatever was the case when the
feature was introduced is irrelevant to my statement.

As demonstrated in this thread, depending on the context, the feature
may or may not optimise the execution speed. I suspect this has always
been the case (in trivial cases, ORing/ANDing everything together is
faster than checking the value of each operand). In principle, the
compiler should be able to detect the cases when the as-if rule allows
non-short circuiting evaluation and and take advantage of it when it
improves the execution speed, but I doubt that many compilers bother
performing such checking.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Robert Bachmann]

Keith Thompson wrote:

If I saw code that used "if (a & b)", my first assumption would be
that it was a typo for "if (a && b)", and my second would be that the
author really intended to test the bitwise "and" of a and b.

When writing something like "if (a & b)" it is a good idea to
write "if (a & b) /*bitwise*/" instead.
On the other hand it looks a little bit funny to me, just like
some beginner who writes "int i; /*an integer variable*/" ;-)

So I for myself always use "if (a bitand b)" instead of
"if (a & b)" (after including <iso646.h> of course),
because with this notation it should be obvious to see that I
did *really* mean & and not &&.

-rb
--
Ro************* @rbdev.net

[Mark A. Odell]

Robert Bachmann <Ro************ *@rbdev.net> wrote in
news:40******** *************** @newsreader02.h ighway.telekom. at:

If I saw code that used "if (a & b)", my first assumption would be
that it was a typo for "if (a && b)", and my second would be that the
author really intended to test the bitwise "and" of a and b.

When writing something like "if (a & b)" it is a good idea to
write "if (a & b) /*bitwise*/" instead.

What's next? When writing this do we need the comment shown?

idx++; /* Increment 'idx' */

just because it might confuse a beginner? You, the developer must write
the code you intend to write. Why should I not believe you meant bit-AND
if you write?

if (reg_a_bits & reg_a_field_mas k)

What is so wrong about C that people aren't comfortable with it?

--
- Mark ->
--

[Keith Thompson]

"Mark A. Odell" <no****@embedde dfw.com> writes:

Robert Bachmann <Ro************ *@rbdev.net> wrote in
news:40******** *************** @newsreader02.h ighway.telekom. at:

If I saw code that used "if (a & b)", my first assumption would be
that it was a typo for "if (a && b)", and my second would be that the
author really intended to test the bitwise "and" of a and b.
When writing something like "if (a & b)" it is a good idea to
write "if (a & b) /*bitwise*/" instead.

What's next? When writing this do we need the comment shown?

idx++; /* Increment 'idx' */

just because it might confuse a beginner?

No, because "idx++;" is unambiguous.

The problem with "if (a & b)" is that it's as likely to be a newbie
mistake (using "&" where "&&" is correct) as a deliberate use of
bitwise-and. I'd rather add a comment than risk having the next
maintainer of the code (who may not be as comfortable with C as I am)
"correct" the "&" to "&&".
You, the developer must write the code you intend to write. Why
should I not believe you meant bit-AND if you write?

if (reg_a_bits & reg_a_field_mas k)

If the variables are called "reg_a_bits " and "reg_a_field_ma sk", it's
not as much of a problem. If they're called "a" and "b" -- well, they
probably shouldn't be unless it's a toy example.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Mark A. Odell]

Keith Thompson <ks***@mib.or g> wrote in
news:ln******** ****@nuthaus.mi b.org:

[snip]

The problem with "if (a & b)" is that it's as likely to be a newbie
mistake (using "&" where "&&" is correct) as a deliberate use of
bitwise-and. I'd rather add a comment than risk having the next
maintainer of the code (who may not be as comfortable with C as I am)
"correct" the "&" to "&&".

In my world of microcontroller s and drivers, & is more common than &&.

You, the developer must write the code you intend to write. Why
should I not believe you meant bit-AND if you write?

if (reg_a_bits & reg_a_field_mas k)

If the variables are called "reg_a_bits " and "reg_a_field_ma sk", it's
not as much of a problem. If they're called "a" and "b" -- well, they
probably shouldn't be unless it's a toy example.

So the real fix might better to continue to write C without junk comments
but to pick variable names that have meaning? I'm all for that.

--
- Mark ->
--

[Old Wolf]

> > > if(expr("1st",1 ) || expr("2nd",0) && expr("3rd",1));

Summary: Operator precedence governs the meaning of an
expression with multiple operators, but does not control
the order in which the operands are evaluated.

Finally a sensible answer in this thread. A corollary is: If you
want to use complex logical expressions, parenthise them so there
is NO DOUBT, NO DOUBT WHATSOEVER, what they mean. You will save a
lot of headaches, both your own and others.

(((((How) (would) (that) (help))?) (The (expressions (
((A || B) && C)
(and)
(A || (B && C))
) (have) ((the) (same) ((order) (of) (evaluation))). )
((There) (was) (never) ((any) (doubt) (about) (((the) (meaning))
(of) ((the) (expression)))) )).

[Robert Bachmann]

Mark A. Odell wrote:

Robert Bachmann <Ro************ *@rbdev.net> wrote in

When writing something like "if (a & b)" it is a good idea to
write "if (a & b) /*bitwise*/" instead. What's next? When writing this do we need the comment shown?
idx++; /* Increment 'idx' */
just because it might confuse a beginner?

No. My point was that someone (a new code maintainer for example)
who reads code like "if (a & b)" can be in doubt that I really
wanted to bitwise-and "a" and "b".

I've often seen code like "if (a & b)" where the developer
actually should have written "if (a && b)".
So it always attracts my attention when I see code like "if (a & b)".
You, the developer must write the code you intend to write. Yes, but nobody is perfect :-)
Why should I not believe you meant bit-AND
if you write?
if (reg_a_bits & reg_a_field_mas k)

If I would have written "if (reg_a_bits & reg_a_field_mas k)"
it should be obvious to anyone that I really liked to bitwise-and
some bits with some mask.
In case "if (a & b)" it is not.
So picking up good (meaningful) variable names (as you already said)
is probably a better solution.

-rb
--
Ro************* @rbdev.net

[CBFalconer]

Robert Bachmann wrote:

Keith Thompson wrote:

If I saw code that used "if (a & b)", my first assumption would be
that it was a typo for "if (a && b)", and my second would be that
the author really intended to test the bitwise "and" of a and b.

When writing something like "if (a & b)" it is a good idea to
write "if (a & b) /*bitwise*/" instead.

On the other hand it looks a little bit funny to me, just like
some beginner who writes "int i; /*an integer variable*/" ;-)

So I for myself always use "if (a bitand b)" instead of
"if (a & b)" (after including <iso646.h> of course),
because with this notation it should be obvious to see that I
did *really* mean & and not &&.

I rarely use the ISO646 stuff, because it seems to bring out the
worst in diehard key savers. When I do, I would prefer to use
'and' for &&, and just & for the bitwise stuff. What I really
want out of ISO646 is and, or, xor, not. These make code much
more readable. They also help to enforce minimum intersymbol blank
standards.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!