Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > AND and OR and parentheses

Reply
Thread Tools

AND and OR and parentheses

 
 
rick
Guest
Posts: n/a
 
      08-15-2005
the following line appears in the K&R book in section 5.7:
leap = year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
my compiler suggests parentheses "around && within ||"

given that the AND operator has higher precedence than OR, would the
correct grouping be this:
leap = (year % 4 == 0 && year % 100 != 0) || year % 400 == 0;
?

thanks,
~rick

 
Reply With Quote
 
 
 
 
Peter Pichler
Guest
Posts: n/a
 
      08-15-2005
rick wrote:

> the following line appears in the K&R book in section 5.7:
> leap = year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
> my compiler suggests parentheses "around && within ||"


I hate that warning. Some compilers can be very fussy, even if the
precedence is obvious.

> given that the AND operator has higher precedence than OR, would the
> correct grouping be this:
> leap = (year % 4 == 0 && year % 100 != 0) || year % 400 == 0;
> ?


Yes.

> thanks,
> ~rick


Peter

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      08-15-2005


rick wrote:
> the following line appears in the K&R book in section 5.7:
> leap = year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
> my compiler suggests parentheses "around && within ||"
>
> given that the AND operator has higher precedence than OR, would the
> correct grouping be this:
> leap = (year % 4 == 0 && year % 100 != 0) || year % 400 == 0;
> ?


Yes; your parentheses don't change the meaning of the
original. The compiler (presumably) issues the warning
because the people who wrote it felt that this is something
programmers often get wrong.

Oddly enough, in this particular case you *can't* get
it wrong! Consider the other possibility:

leap = year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);

This expression gives the same value to `leap' as the first
(equivalent) pair, even though it arrives at the value by a
different route.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-15-2005
Eric Sosman wrote:
> rick wrote:
>
>> the following line appears in the K&R book in section 5.7:
>> leap = year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
>> my compiler suggests parentheses "around && within ||"
>>
>> given that the AND operator has higher precedence than OR, would
>> the correct grouping be this:
>> leap = (year % 4 == 0 && year % 100 != 0) || year % 400 == 0;

>
> Yes; your parentheses don't change the meaning of the
> original. The compiler (presumably) issues the warning
> because the people who wrote it felt that this is something
> programmers often get wrong.
>
> Oddly enough, in this particular case you *can't* get
> it wrong! Consider the other possibility:
>
> leap = year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
>
> This expression gives the same value to `leap' as the first
> (equivalent) pair, even though it arrives at the value by a
> different route.


Actually that last is probably the most efficient, since 75% of the
time the value is resolved with one test, 24% with two tests, and
1% with three. I would use even more parens, as in:

leap = (year % 4 == 0) &&
((year % 100 != 0) || (year % 400 == 0));

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson


 
Reply With Quote
 
akarl
Guest
Posts: n/a
 
      08-16-2005
CBFalconer wrote:
> Eric Sosman wrote:
>
>>rick wrote:
>>
>>
>>>the following line appears in the K&R book in section 5.7:
>>> leap = year % 4 == 0 && year % 100 != 0 || year % 400 == 0;
>>>my compiler suggests parentheses "around && within ||"
>>>
>>>given that the AND operator has higher precedence than OR, would
>>>the correct grouping be this:
>>> leap = (year % 4 == 0 && year % 100 != 0) || year % 400 == 0;

>>
>> Yes; your parentheses don't change the meaning of the
>>original. The compiler (presumably) issues the warning
>>because the people who wrote it felt that this is something
>>programmers often get wrong.
>>
>> Oddly enough, in this particular case you *can't* get
>>it wrong! Consider the other possibility:
>>
>> leap = year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
>>
>>This expression gives the same value to `leap' as the first
>>(equivalent) pair, even though it arrives at the value by a
>>different route.

>
>
> Actually that last is probably the most efficient, since 75% of the
> time the value is resolved with one test, 24% with two tests, and
> 1% with three. I would use even more parens, as in:
>
> leap = (year % 4 == 0) &&
> ((year % 100 != 0) || (year % 400 == 0));
>


Yes, I think parentheses around the "boolean" (atomic) expressions
improve readability considerably, it's also customary in mathematics.
(However, I think relying on the precedence of `and' over `or' is
perfectly okay.)

August
 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      08-17-2005

"akarl" <(E-Mail Removed)> wrote
>
> Yes, I think parentheses around the "boolean" (atomic) expressions improve
> readability considerably, it's also customary in mathematics. (However, I
> think relying on the precedence of `and' over `or' is perfectly okay.)
>

The rule I use is that you can rely on your reader to know that * and / have
a higher precedence than + and -, and everything else needs parentheses.


 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      08-17-2005
"Malcolm" <(E-Mail Removed)> wrote:

> "akarl" <(E-Mail Removed)> wrote
> >
> > Yes, I think parentheses around the "boolean" (atomic) expressions improve
> > readability considerably, it's also customary in mathematics. (However, I
> > think relying on the precedence of `and' over `or' is perfectly okay.)
> >

> The rule I use is that you can rely on your reader to know that * and / have
> a higher precedence than + and -, and everything else needs parentheses.


Are you sure?

#include <stdio.h>

int main(void)
{
int i, j;

for ((i=1); (i<10); (i++)) {
(j=(i*10+3));
(printf(("Value nr. %d is %d\n"), (i), (j)));
}
}

Richard
 
Reply With Quote
 
Netocrat
Guest
Posts: n/a
 
      08-17-2005
On Wed, 17 Aug 2005 06:38:50 +0000, Richard Bos wrote:

> "Malcolm" <(E-Mail Removed)> wrote:
>
>> "akarl" <(E-Mail Removed)> wrote
>> >
>> > Yes, I think parentheses around the "boolean" (atomic) expressions improve
>> > readability considerably, it's also customary in mathematics. (However, I
>> > think relying on the precedence of `and' over `or' is perfectly okay.)
>> >

>> The rule I use is that you can rely on your reader to know that * and / have
>> a higher precedence than + and -, and everything else needs parentheses.

>
> Are you sure?
>
> #include <stdio.h>
>
> int main(void)
> {
> int i, j;
>
> for ((i=1); (i<10); (i++)) {
> (j=(i*10+3));
> (printf(("Value nr. %d is %d\n"), (i), (j)));
> }
> }


Well if we're going to take Malcolm's statement literally without applying
common sense, this would be even better (we could go indefinitely further):

#include <stdio.h>

int main(void)
{
int i, j;

for ((((i=1))); (((i<10))); (((i++)))) {
(((j=(((i*10+3))))));
(((printf(((("Value nr. %d is %d\n"))), (((i))), (((j)))))));
}
}

I think that both of these fail to capture his intent.

--
http://members.dodo.com.au/~netocrat

 
Reply With Quote
 
Netocrat
Guest
Posts: n/a
 
      08-17-2005
On Wed, 17 Aug 2005 02:44:53 -0700, Suman wrote:
> Netocrat wrote:
>> On Wed, 17 Aug 2005 06:38:50 +0000, Richard Bos wrote:
>> > "Malcolm" <(E-Mail Removed)> wrote:
>> >> "akarl" <(E-Mail Removed)> wrote
>> >> >
>> >> > Yes, I think parentheses around the "boolean" (atomic) expressions
>> >> > improve readability considerably, it's also customary in
>> >> > mathematics. (However, I think relying on the precedence of `and'
>> >> > over `or' is perfectly okay.)
>> >> >
>> >> The rule I use is that you can rely on your reader to know that *
>> >> and / have a higher precedence than + and -, and everything else
>> >> needs parentheses.

>
> He m[i/e]ssed up with the last part of the sentence. Here it is for your
> viewing pleasure:
>
> With the usual exceptions, of course.


Yes, obviously that's what Malcolm meant and he shouldn't be required to
write it (which he didn't according to my newsfeed).

> [snipped a lot of code from fertile minds]
>
> C'mon guys -- be a sport.


I thought I was being - the point of my post was that the literal and
strict interpretation of what was clearly a helpful guideline rather than
a formal rule was lacking in common sense and obviously wasn't what was
intended. Hence the first line of my post: "if we're going to [not apply]
common sense" and the final line:

> I think that both of these fail to capture his intent.


--
http://members.dodo.com.au/~netocrat

 
Reply With Quote
 
Suman
Guest
Posts: n/a
 
      08-17-2005

Netocrat wrote:
> On Wed, 17 Aug 2005 06:38:50 +0000, Richard Bos wrote:
>
> > "Malcolm" <(E-Mail Removed)> wrote:
> >
> >> "akarl" <(E-Mail Removed)> wrote
> >> >
> >> > Yes, I think parentheses around the "boolean" (atomic) expressions improve
> >> > readability considerably, it's also customary in mathematics. (However, I
> >> > think relying on the precedence of `and' over `or' is perfectly okay.)
> >> >
> >> The rule I use is that you can rely on your reader to know that * and / have
> >> a higher precedence than + and -, and everything else needs parentheses.


He m[i/e]ssed up with the last part of the sentence. Here it is for
your
viewing pleasure:

With the usual exceptions, of course.

[snipped a lot of code from fertile minds]

C'mon guys -- be a sport.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
parentheses and newlines jsnark Ruby 2 02-18-2012 07:56 PM
Parentheses and compiler optimzation spasmous C Programming 15 04-13-2008 03:35 AM
Eliminating Parentheses and Words Between Them In Word Doc Martin Computer Support 9 07-13-2007 07:06 AM
C parentheses, brackets and brace case.learning@gmail.com C Programming 8 06-16-2007 12:41 AM
Substitution and Text Within Parentheses Addy Perl Misc 2 08-26-2003 01:15 PM



Advertisments