Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #141940

Re: Remembering C's operator precedence rules

Show all headers | View raw

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Prompted by recent posts about remembering C's 15 precedence
> levels for its 49 operators, I thought I would gather together
> some remarks [...]

> So how do you either remember these, or work them out from first
> principles?  Do you have any handy mnemonics or idiomatic examples
> to share?

I don't do well at rote memorization.  I hardly ever try to
memorize something "by heart", where it's all done just by
memory.  In fact, pretty much the opposite - normally I want
to remember as little as possible, and let logic fill in the
rest.  Here are my own mnemonic aids for C expression syntax.

Let's forget for a moment about bitwise operators (the shift
operators and the binary logical operators &, ^, |).  I don't
need to do anything special to remember how everything else
works:  everything goes where I would expect it to go, assuming
The Law of Least Astonishment.  Well, almost everything.  There
are two wrinkles:  casting, and comparisons.

There's a little dance that happens with cast operators and
prefix unary expressions.  A cast is _almost_ like a prefix
operator, but there are some exceptions.  Fortunately the
exceptions are things that either don't make sense or are
ambiguous.  So I don't have to worry about these cases,
because they never come up, or if they do the compiler will
remind me to stay out of those places.  Although the syntax
rules separate casts and prefix operators, in practice they
can be treated as the same (perhaps remembering the asterisk
that says "well not exactly").

The splitting of comparison operators into two strata (ordering
and equality/inequality) is suprising.  I think though that the
reason it's surprising is just an accident of history (ie, my own
personal history in earlier learning).  C doesn't group operators
together (in particular, binary operators) unless they are very
closely related.  Ordering comparisons and equality comparisons
are superficially related, but in usage are rather dissimilar.
Consider:

  floating point - almost always use ordering comparisons,
                   only very rarely equality/inequality

  pointers       - all pointers can be compared for (in)equality;
                   only some pointers can be compared for order

  complex number - equality/inequality allowed;  comparing for
                   relative order is not even allowed

Before learning C I wouldn't have guessed that comparison
operators would occupy two different precedence levels.  Now that
I know C, it isn't nearly so surprising, and in fact even almost
natural.  Ordering and equality are very different sorts of
relationships.  Once I know they are different, which group takes
precedence follows from the law of least astonishment.

Minor digression:  I don't have any trouble with the relative
order of &, ^, and |, especially since knowing that they are "low
budget" logical connectives, and therefore underneath the
[in]equality operators, that all fits together nicely, with ==/!=
being "low budget" EQV/XOR logical operators, conveniently on the
other side of & from ^.  I also have an example (which believe it
or not came up in actual code) for a separate reinforcement.  We
have words (eg, unsigned) w and v, and we want the value in w
updated by v under control of MASK.  This expression:

    w&MASK ^ w  |  v&MASK

gives the value desired.  (Yes this also could have been done
using ~ and without the ^, but there was some reason not to do
that in the original context.)  Note that relative precedence is
reflected in the spacing of the operators/operands:  the larger
the number of spaces around an operator, the lower its
precedence.  (End of minor digression.)

Now all that's left is what to do with the (binary) bitwise
operators.  My device for that is this:  the bitwise operators
make a "sandwich" around the comparison operators.  I know the
logical operators go underneath because originally C did not
have the short-circuiting logical operators, so the bitwise
operators served as logical connections, and were kept there
for historical reasons.  The "sandwich" mnemonic solidifies
the whole picture for me very nicely, which makes it easy
to see how any given expression parses.

These bits and pieces are enough for me.  I don't mean to suggest
that they are enough for everyone, especially since different
people have very different learning modes.  The key is to find
a set of mnemonic aids that works for _you_.  (I am happy to
make specific suggestions if someone gets stuck somewhere.)

Also, one more thing.  At some point I adopted the habit of using
spacing to show grouping, both for myself and for other people,
in cases where I thought there might be some uncertainty (and
also other cases, depending).  I have found that doing this
reinforces what I have learned, during both the writing of code
and the reading of code.  Using (redundant) parentheses to
indicate grouping makes it easy to forget;  using spacing to
indicate grouping makes it easy to remember.  I recommend leaving
out redundant parentheses in almost all cases, and instead using
spacing to indicate grouping.  The result will benefit both you
and your readers.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-09 16:53 +0000
  Re: Remembering C's operator precedence rules Richard Damon <Richard@Damon-Family.org> - 2019-03-09 15:21 -0500
    Re: Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-09 21:41 +0000
  Re: Remembering C's operator precedence rules Keith Thompson <kst-u@mib.org> - 2019-03-09 12:32 -0800
    Re: Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-09 21:21 +0000
      Re: Remembering C's operator precedence rules Richard Damon <Richard@Damon-Family.org> - 2019-03-09 16:42 -0500
        Re: Remembering C's operator precedence rules "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-09 14:01 -0800
      Re: Remembering C's operator precedence rules Keith Thompson <kst-u@mib.org> - 2019-03-09 14:17 -0800
        Re: Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-10 00:42 +0000
  Re: Remembering C's operator precedence rules Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-03-09 13:54 -0700
    Re: Remembering C's operator precedence rules Bart <bc@freeuk.com> - 2019-03-09 21:37 +0000
      Re: Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-09 22:01 +0000
      Re: Remembering C's operator precedence rules Richard Damon <Richard@Damon-Family.org> - 2019-03-09 18:59 -0500
        Re: Remembering C's operator precedence rules Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-13 09:26 -0700
    Re: Remembering C's operator precedence rules Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-13 10:11 -0700
      Re: Remembering C's operator precedence rules Bart <bc@freeuk.com> - 2019-03-13 17:40 +0000
        Re: Remembering C's operator precedence rules Keith Thompson <kst-u@mib.org> - 2019-03-13 15:24 -0700
          Re: Remembering C's operator precedence rules Bart <bc@freeuk.com> - 2019-03-13 23:43 +0000
            Re: Remembering C's operator precedence rules Keith Thompson <kst-u@mib.org> - 2019-03-13 17:43 -0700
        Re: Remembering C's operator precedence rules Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-18 08:53 -0700
      Re: Remembering C's operator precedence rules Wouter Verhelst <w@uter.be> - 2019-03-13 22:24 +0200
        Re: Remembering C's operator precedence rules Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-13 14:06 -0700
        Re: Remembering C's operator precedence rules Ian Collins <ian-news@hotmail.com> - 2019-03-14 14:28 +1300
          Re: Remembering C's operator precedence rules scott@slp53.sl.home (Scott Lurndal) - 2019-03-14 13:35 +0000
            Re: Remembering C's operator precedence rules Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-14 06:55 -0700
            Re: Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-14 16:39 +0000
              Re: Remembering C's operator precedence rules scott@slp53.sl.home (Scott Lurndal) - 2019-03-14 17:37 +0000
                Re: Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-14 20:42 +0000
              Re: Remembering C's operator precedence rules Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-14 10:42 -0700
                Re: Remembering C's operator precedence rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-14 23:08 +0000
                Re: Remembering C's operator precedence rules Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-15 02:53 -0700
                Re: Remembering C's operator precedence rules Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-03-15 17:52 -0600
  Re: Remembering C's operator precedence rules Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-13 12:56 -0700
  Re: Remembering C's operator precedence rules Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2019-03-13 20:14 +0000
  Re: Remembering C's operator precedence rules fir <profesor.fir@gmail.com> - 2019-03-19 14:17 -0700

csiph-web