On Wed, Apr 11, 2012 at 11:18 AM, Ian Lance Taylor <i...@google.com> wrote:
> Andrew Haley <a...@redhat.com> writes:
>
>> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>>
>>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>>> which did not cause a warning on older gcc version now gives a
>>> warning. I would not want it on by default since it forces users to
>>> write too many parentheses in ((a&&b)||(c&&d)) which makes the
>>> expression less readable. What next? Warn about (a*b+c*d) ? I would
>>> hate to write ((a*b)+(c*d)).
>>>
>>> Sure, the precedence of: << vs. +; & vs. == ; & vs. && ; is less
>>> clear and deserves a warning, but: & vs. | ; && vs. || ; are at
>>> least as common as * vs. + that programmers ought to know them.
>>
>> Absolutely so, yes.  I'd consider this a bug in gcc, just as if it
>> warned for arithmetic.
>
> This one is an interesting case, since there are strong arguments on
> both sides.
>
> I enabled the C++ warning about the precedence of && and || (it's been
> in C for many years).  It found real bugs in real code, bugs that had
> existed for years.

Indeed; although I follow GCC conventions while writing code for integration
into GCC, in my own code I'd much rather write ((a*b)+(c*d)) and deal with
any readability issues by adding whitespace.

Making the intent explicit seems safer than making assumptions about the
expertise level of the people who will be reading and maintaining the code,
or adding to the cognitive load of a maintainer who does remember the
precedence rules.

(Not even hinting for a change in GCC style: it's your bikeshed, I just
visit once in a while.)

Peter

Reply via email to