From: Ross Smith <r-smith@ihug.co.nz>
To: Paul Brook <paul@codesourcery.com>
Cc: gcc@gcc.gnu.org, "James K. Lowden" <jklowden@freetds.org>,
Ian Lance Taylor <iant@google.com>
Subject: Re: -Wparentheses lumps too much together
Date: Fri, 21 Dec 2007 20:19:00 -0000 [thread overview]
Message-ID: <476C1461.2050107@ihug.co.nz> (raw)
In-Reply-To: <200712201509.20582.paul@codesourcery.com>
Paul Brook wrote:
>James K. Lowden wrote:
>>
>> 1) most combinations of && and || don't need parentheses because
>>
>> (a && b) || (c && d)
>>
>> is by far more common than
>>
>> a && (b || c) && d
>>
>> and, moreover, broken code fails at runtime, and
>
> I dispute these claims.
>
> The former may be statistically more common, but I'd be surprised if the
> difference is that big. I can think of several fairly common situations where
> both would be used.
>
> Any time you've got any sort of nontrivial condition, I always find it better
> to include the explicit parentheses. Especially if a, b, c, and d are
> relatively complex relational expressions rather than simple variables.
I second Paul's points. The precedence of && and || are not widely
enough known that warning about it should be off by default (for people
sane enough to use -Wall).
A couple of data points:
First, I've been writing C and C++ for a living for nearly 20 years now,
and I didn't know that && had higher precedence than ||. I vaguely
recalled that they had different precedence, but I couldn't have told
you which came first without looking it up. I'd happily bet that the
same is true of the overwhelming majority of developers who aren't
compiler hackers. Giving && and || different precedence is one of those
things that feels so totally counterintuitive that I have trouble
remembering it no matter how many times I look it up. I have a firm
coding rule of always parenthesising them when they're used together.
(Likewise &, |, and ^, which have similar issues. I can't remember
whether -Wparentheses warns about those too.)
Second, I just grepped the codebase I'm curently working on (about 60k
lines of C++) for anywhere && and || appear on the same line. I got 49
hits, 29 where && was evaluated before ||, 20 the other way around. (All
of them, I'm happy to say, properly parenthesised.) So while
&&-inside-|| seems to be slightly more common, I'd certainly dispute
James's claim that it's "far more common".
-- Ross Smith
next prev parent reply other threads:[~2007-12-21 19:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 20:07 jklowden
2007-12-19 20:14 ` Doug Gregor
2007-12-19 20:39 ` Ismail Dönmez
2007-12-19 20:15 ` Daniel Jacobowitz
2007-12-19 23:11 ` Ian Lance Taylor
2007-12-20 6:08 ` James K. Lowden
2007-12-20 16:41 ` Paul Brook
2007-12-21 20:19 ` Ross Smith [this message]
2008-01-11 7:34 ` Rehno Lindeque
2008-01-11 17:00 ` Joe Buck
2008-01-11 17:05 ` Robert Dewar
2008-01-11 23:26 ` Ian Lance Taylor
2008-01-12 0:50 ` Joe Buck
2007-12-20 18:01 ` Ian Lance Taylor
2007-12-21 5:28 ` James K. Lowden
2007-12-21 9:27 ` Ralf Wildenhues
2007-12-21 17:16 ` NightStrike
2008-01-11 22:44 ` Doug Gregor
2008-01-12 3:48 ` Ian Lance Taylor
2008-01-12 10:16 ` Andreas Schwab
2008-01-12 11:23 ` Paolo Bonzini
2008-01-13 16:03 ` Gabriel Dos Reis
2008-03-10 17:25 Derek M Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=476C1461.2050107@ihug.co.nz \
--to=r-smith@ihug.co.nz \
--cc=gcc@gcc.gnu.org \
--cc=iant@google.com \
--cc=jklowden@freetds.org \
--cc=paul@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).