Fundamental question
myName
is evaluated as
(a && b) || c
or it is evaluated as
a && (b || c)
The theory and logic says it's (a && b) || c
Does it depends on compilar also ?
I don't think so.
In my view the 1st is the ultimate answer.
What you people say ?
Ajay
Pieter Droogendijk
> a && b || c
>
> is evaluated as
>
> (a && b) || c
>
> or it is evaluated as
>
> a && (b || c)
The && operator has a higher precedence than ||. Therefore, a && b is
evaluated first. That makes that
a && b || c
is evaluated as
(a && b) || c
> Does it depends on compilar also ?
No. It depends on the standard. And the standard says it's (a && b) || c.
> I don't think so.
You thought right.
> In my view the 1st is the ultimate answer.
> What you people say ?
I say the first is the only answer.
--
int main(void){int putchar(int),i=0;unsigned long t=500555079,n[]={t
,159418370,88921539,286883974,80500161,0};while(n[i])putchar(*(!(t&1
)+!(t||!++i)+"# \n")),(t&&1+(t>>=i-~-i))||(t=n[i]^n[i-1]);return 0;}
Jarno A Wuolijoki
> a && b || c
> is evaluated as
> (a && b) || c
> or it is evaluated as
> a && (b || c)
>
> The theory and logic says it's (a && b) || c
This is correct on every conforming compiler.
I guess the logic is that with values 0 and 1, && is similar to
multiplication and || similar to (saturated) addition and this is
reflected in their relative precedence.
(possibly another useful analogy would be min/max but C doesn't
have operators for those..)
Richard Bos
> On Fri, 04 Jun 2004 15:48:30 +0530, myName wrote:
>
> > a && b || c
> >
> > is evaluated as
> >
> > (a && b) || c
> >
> > or it is evaluated as
> >
> > a && (b || c)
>
> The && operator has a higher precedence than ||. Therefore, a && b is
> evaluated first. That makes that
> a && b || c
> is evaluated as
> (a && b) || c
And note: unlike what is true for most other operators, these operands
are evaluated in order, left to right, and when the outcome can be
determined from the operands that have already been evaluated, the
others won't be. For example, in
a*b - c
the order of evaluation could be: first c, then b, then a, then the
multiplication, then the subtraction. Another could be: first b, then a,
then the multiplication, then c, then the subtraction. The only things
you know about the order is that, obviously, the operands must be
evaluated before their operations are performed; and the multiplication
will happen before the subtraction. However, in
a && b || c
the order _must_ be:
evaluate a
if a, then
evaluate b
do logical and
else
result of logical and is guaranteed to be 0
b is not evaluated
if result of and is 0
evaluate c
do logical or
else
logical or is guaranteed to result in 1
c is not evaluated
It is also the case that, while a || b && c has the _value_ of a || (b
&& c), the operands are still evaluated in left-to-right order; that is,
if a is non-zero, the whole of the expression is true, and neither b nor
c need or will be evaluated.
This is a useful feature, because you can do things like
if (ptr!=NULL && *ptr<MAX_VALUE)
without worrying that *ptr might be evaluated before you've checked that
ptr is not null.
Richard
Pieter Droogendijk
> Pieter Droogendijk <gi...@binSPAMky.homFOReunix.orMEg> wrote:
>> The && operator has a higher precedence than ||. Therefore, a && b is
>> evaluated first. That makes that
>> a && b || c
>> is evaluated as
>> (a && b) || c
>
> And note: unlike what is true for most other operators, these operands
> are evaluated in order, left to right, and when the outcome can be
> determined from the operands that have already been evaluated, the
> others won't be.
...this because there is a sequence point after the first operand to &&
and ||.
Dan Pop
osmium
> >a && b || c
> >
> >is evaluated as
> >
> >(a && b) || c
> >
> >or it is evaluated as
> >
> >a && (b || c)
> >
> >The theory and logic says it's (a && b) || c
> >Does it depends on compilar also ?
> >I don't think so.
> >In my view the 1st is the ultimate answer.
> >What you people say ?
>
> What does your C book say?
If you looked at 100 "C books" at random, how many times would you expect
his question to be answered? Either rightly or wrongly. If you think some
things are so basic as to be unworthy of discussion why not just simply say
so? Or even, God forbid, ignore the question.
Dan Pop
>Dan Pop writes:
>
>> >a && b || c
>> >
>> >is evaluated as
>> >
>> >(a && b) || c
>> >
>> >or it is evaluated as
>> >
>> >a && (b || c)
>> >
>> >The theory and logic says it's (a && b) || c
>> >Does it depends on compilar also ?
>> >I don't think so.
>> >In my view the 1st is the ultimate answer.
>> >What you people say ?
>>
>> What does your C book say?
>
>If you looked at 100 "C books" at random, how many times would you expect
>his question to be answered? Either rightly or wrongly.
100. I don't expect any tutorial C book not to cover the operator
precedence or to get it so blatantly wrong.
>If you think some
>things are so basic as to be unworthy of discussion why not just simply say
>so?
Because my actual answer also conveys the message, to the OP and to other
people reading this newsgroup, that such issues should be first solved
with a C book. In the unlikely case that the C book doesn't provide the
answer, the question should be posted here, by explicitly mentioning that
book X doesn't provide the answer.
>Or even, God forbid, ignore the question.
Off topic questions should not be ignored!
There is a huge difference between looking up the answer in the book and
getting the wrong answer and posting here without looking it up in the
book. By your idiotic logic, we should encourage people to post their
most basic questions here, *instead* of looking up the answers in their
book first, because their books *may* provide the wrong answers or no
answer at all.
After reading this newsgroup for over 10 years, I am not aware of any
complaints about books getting the relative precedence of these two
operators wrong...
Guillaume
So, before considering what the compiler will do, what do YOU
understand when reading this logic statement?
As for me, it confuses the hell out of me.
Just use parentheses and get over the "fundamental" question.
Keith Thompson
> On Fri, 04 Jun 2004 10:57:28 +0000, Richard Bos wrote:
> > Pieter Droogendijk <gi...@binSPAMky.homFOReunix.orMEg> wrote:
> >> The && operator has a higher precedence than ||. Therefore, a && b is
> >> evaluated first. That makes that
> >> a && b || c
> >> is evaluated as
> >> (a && b) || c
> >
> > And note: unlike what is true for most other operators, these operands
> > are evaluated in order, left to right, and when the outcome can be
> > determined from the operands that have already been evaluated, the
> > others won't be.
>
> ...this because there is a sequence point after the first operand to &&
> and ||.
Well, not quite. It's true that there's a sequence point after the
first operand, but that alone doesn't imply that the second operand
won't be evaluated (short-circuit behavior). Conversely, though, the
existence of the sequence point is probably necessary to allow the
determination of whether the right operand needs to be evaluated.
The && and || operators are evaluated with short-circuit behavior
because the standard says so. It could as easily have stated that the
operands are evaluated in order, that there's a sequence point after
the evaluation of the left operand, and that both operands are always
evaluated (though of course that would have broken tons of existing
code).
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson
> Binary logic operators have the same priority, as far as I know.
You're mistaken. Please consult a book or other reference before
posting misinformation.
> As for me, it confuses the hell out of me.
> Just use parentheses and get over the "fundamental" question.
That's good advice if you're writing code, but less so if you're
reading code whose author assumed that you know the relative
precedence of the && and || operators.
Mark McIntyre
<r124c...@comcast.net> wrote:
>Dan Pop writes:
>
>>
>> What does your C book say?
>
>If you looked at 100 "C books" at random, how many times would you expect
>his question to be answered?
about 100, if they were sensible book choices for beginners who didn't know
something like this.
>Either rightly or wrongly. If you think some
>things are so basic as to be unworthy of discussion why not just simply say
>so?
In this case, I do think Dan was right to suggest that a book might be more
useful than usenet.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Guillaume
>
> [...]
>
> You're mistaken. Please consult a book or other reference before
Thanks. I don't need to, though. I've been using C for more than 10
years in professional settings. ;-)
There is a precedence scheme when using && and || logic operators
in C, but it's not equivalent to algebraic priority, because
it not only depends on the operators, but on the values of the
boolean arguments as well. Thus, this doesn't qualify as classic
priority, and technically, yes, we can absolutely say that && and
|| have the same priority, albeit with a particular behavior
that, of course, must be known when using C.
In particular, a && b is not functionally equivalent to b && a
if a or b have side-effects.
Hence, the logic operators are not commutative in C, and cannot
be factored in an obvious way in the general case, unless no part of
the boolean expression has side-effects.
The aforementioned expression was deterministic, but highly
unreadable. This is the point I was making.
John Smith
Dan, how many times do you kick your dog when you get home from
work at night?
Barry Schwarz
<grsN...@NO-SPAMmail.com> wrote:
>>>Binary logic operators have the same priority, as far as I know.
>>
>> [...]
>>
>> You're mistaken. Please consult a book or other reference before
>
>Thanks. I don't need to, though. I've been using C for more than 10
>years in professional settings. ;-)
>
>There is a precedence scheme when using && and || logic operators
>in C, but it's not equivalent to algebraic priority, because
>it not only depends on the operators, but on the values of the
>boolean arguments as well. Thus, this doesn't qualify as classic
>priority, and technically, yes, we can absolutely say that && and
>|| have the same priority, albeit with a particular behavior
Any claim that && and || have the same precedence is just wrong.
>that, of course, must be known when using C.
>
>In particular, a && b is not functionally equivalent to b && a
>if a or b have side-effects.
>Hence, the logic operators are not commutative in C, and cannot
>be factored in an obvious way in the general case, unless no part of
>the boolean expression has side-effects.
>
>The aforementioned expression was deterministic, but highly
>unreadable. This is the point I was making.
<<Remove the del for email>>
Keith Thompson
> >>Binary logic operators have the same priority, as far as I know.
> > [...]
> > You're mistaken. Please consult a book or other reference before
>
> Thanks. I don't need to, though. I've been using C for more than 10
> years in professional settings. ;-)
Then why do you still seem to believe that "[b]inary logic operators
have the same priority"? You can quibble about the distinction
between "priority" and "precedence" (though if you meant to make such
a distinction you should have made it clear in the first place).
The || and && operators have different precedence in C. Any statement
to the contrary is simply incorrect. Any C programmer needs to know
this, or at least needs to be recognize the need to look it up when
necessary.
[...]
> The aforementioned expression was deterministic, but highly
> unreadable. This is the point I was making.
That was one of the points you made, and I (mostly) agree with it.
Chris Dollin
>>>Binary logic operators have the same priority, as far as I know.
>>
>> [...]
>>
>> You're mistaken. Please consult a book or other reference before
>
> Thanks. I don't need to, though. I've been using C for more than 10
> years in professional settings. ;-)
>
> There is a precedence scheme when using && and || logic operators
> in C, but it's not equivalent to algebraic priority, because
> it not only depends on the operators, but on the values of the
> boolean arguments as well.
Wrong. The precedence is syntactic, and [hence] independant of the
values of the operands.
> Thus, this doesn't qualify as classic
> priority, and technically, yes, we can absolutely say that && and
> || have the same priority,
No. See below.
> albeit with a particular behavior
> that, of course, must be known when using C.
>
> In particular, a && b is not functionally equivalent to b && a
> if a or b have side-effects.
Yes. This, however, to do with order-of-evaluation, *not* precedence.
Precedence [and associativity] allows us to determine that
a || b && c means a || (b && c)
not (a || b) && c
which differ when (a=true and c=false), with not a side-effect
in sight, nor any dependance on short-circuit evaluation.
[Clearly if these operators right-associated, I could produce
another counter-example by switching || and &&].
Thus your claim of "equal priority" is refuted.
> The aforementioned expression was deterministic, but highly
> unreadable. This is the point I was making.
"Highly unreadable" is a rather intense way to say "potentially
confusing".
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
Dan Pop
>Dan, how many times do you kick your dog when you get home from
>work at night?
10 times for each question whose answer can be trivially found in K&R2
or in the FAQ. However, she seems to be an expert in these documents,
as she never asked me any such question...
Dan ;-)
Guillaume
Is it? I'm not sure you understood what I meant by that.
If && and || don't have equal priority, which of them
has higher priority then? Good luck. ;-)
Both logical operators guarantee left-to-right evaluation,
and that is it. This does not add up to different priority
in the algebraic sense, as in: 'A + B * C'. This is what
I meant. '*' has higher priority than '+'.
Is what I said clearer now?
Keith Thompson
No, it isn't.
I thought you were making some distinction between priority and
precedence, but I don't think you are.
A + B * C is equivalent to A + (B * C), so "*" has higher precedence
than "+".
A || B && C is equivalent to A || (B && C), so "&&" has higher
precedence than "||".
The "&&" and "||" operators are evaluated left-to-right, with
short-circuit semantics, but that's a separate issue. For "+" and
"*", precedence is a question of which operators apply to which
operands; it's more syntactic than semantic. The precedence of the
"&&" and "||" operators is determined in exactly the same way.
Ben Pfaff
>> Thus your claim of "equal priority" is refuted.
>
> Is it? I'm not sure you understood what I meant by that.
>
> If && and || don't have equal priority, which of them
> has higher priority then? Good luck. ;-)
You're using an undefined term here. There's no reference to
"priority" in the C standard. I think you're thinking of
"precedence", which is at least referenced in sidelong ways in
the Standard.
The && operator has higher precedence than || does in C. You can
read the grammar given in the C standard to verify this:
logical-AND-expression:
inclusive-OR-expression
logical-AND-expression && inclusive-OR-expression
logical-OR-expression:
logical-AND-expression
logical-OR-expression || logical-AND-expression
> Both logical operators guarantee left-to-right evaluation,
> and that is it. This does not add up to different priority
> in the algebraic sense, as in: 'A + B * C'. This is what
> I meant. '*' has higher priority than '+'.
I don't think mathematicians call this priority either. It is
the "order of operations" or "precedence" of operators. Again,
&& has higher precedence than ||.
> Is what I said clearer now?
No. You're not using the right terms.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup
J. J. Farrell
> Guillaume <grsN...@NO-SPAMmail.com> writes:
> >
> > Binary logic operators have the same priority, as far as I know.
> [...]
>
> You're mistaken. Please consult a book or other reference before
> posting misinformation.
Or, even better, skip the posting of misinformation altogether.
Mind you, since C doesn't have a concept of "priority", how do
we know he's mistaken? It depends on just what he means by it.
Mabden
> Guillaume <grsN...@NO-SPAMmail.com> writes:
> The "&&" and "||" operators are evaluated left-to-right, with
> short-circuit semantics, but that's a separate issue. For "+" and
> "*", precedence is a question of which operators apply to which
> operands; it's more syntactic than semantic. The precedence of the
> "&&" and "||" operators is determined in exactly the same way.
K&R page #41 has an if that goes like this:
if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0)
printf ("%d is a leap year\n", year);
So I guess the parenthesis in the && clause are unnecessary?!
It's not like K&R to be so verbose! ;-)
--
Mabden
Keith Thompson
The parentheses aren't strictly necessary, in the sense that the
expression would have the same semantics without them. But it's
perfectly sensible to add them when they make the code easier to read
-- especially in code intended to be read by beginners.
Chris Dollin
>> Thus your claim of "equal priority" is refuted.
>
> Is it? I'm not sure you understood what I meant by that.
I'm pretty sure I did.
> If && and || don't have equal priority, which of them
> has higher priority then? Good luck. ;-)
&&. What, you thought I didn't *know*?
> Both logical operators guarantee left-to-right evaluation,
> and that is it. This does not add up to different priority
> in the algebraic sense, as in: 'A + B * C'.
It's true that order of evaluation doesn't "add up to different
priority in the algebraic sense". That doesn't mean that && and
|| don't have different priorities.
> This is what I meant. '*' has higher priority than '+'.
Just as && has a higher priority (is more binding than, has shorter
scope than) ||.
> Is what I said clearer now?
No, it's just as clear, and still wrong.
If && and || had the same priority, then
a || b && c
would mean [assuming the usual left association]
(a || b) && c
but - as I pointed out last time - it doesn't; the two expressions
have different values when a=true and c=false. You failed to address
this point. Just for kicks:
#include <stdio.h>
int main(void)
{
int a, b, c;
for (a = 0; a < 2; a += 1)
for (b = 0; b < 2; b += 1)
for (c = 0; c < 2; c += 1)
if ((a || b && c) != ((a || b) && c))
printf( ">> differ when a=%d, b=%d, c=%d\n", a, b, c );
return 0;
Dan Pop
Yup, it's clear that you're dead wrong. && has higher precedence than ||
in exactly the same way '*' has higher precedence than '+'. In other
words, the expression A || B && C is evaluated as A || (B && C) and not
as (A || B) && C. The shortcircuiting feature of the && and || operators
will suppress the evaluation of parts of the expression, if they are
irrelevant to the final result, but this doesn't affect the relative
precedence of the two operators. The order of evaluation of the operands
of A || B && C is strictly defined, while the order of evaluation of the
operands of A + B * C is not, but this has nothing to do with operator
precedence.
Dan
Dale Henderson
Mabden> K&R page #41 has an if that goes like this:
Mabden> if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0)
Mabden> printf ("%d is a leap year\n", year);
Mabden> So I guess the parenthesis in the && clause are
Mabden> unnecessary?! It's not like K&R to be so verbose! ;-)
Extraordinarily verbose considering my code for the same thing
often looks like:
if( !(year%4)&&year%100||!(year%400))
printf ("%d is a leap year\n",year);
If && and || had the same precedence the parenthesis would still
be unnecessary.
K&R2 page #53 has a precedence table which clearly shows && to
have the higher priority.
(Before reading this thread, I thought && and || had the same
precedence. I'm better now.)
--
Dale Henderson
"Imaginary universes are so much more beautiful than this stupidly-
constructed 'real' one..." -- G. H. Hardy