Groups > comp.lang.c > #20628

Re: Operator precedence.

From	"BartC" <bc@freeuk.com>
Newsgroups	comp.lang.c
Subject	Re: Operator precedence.
Date	2012-05-11 22:21 +0100
Organization	A noiseless patient Spider
Message-ID	<jok019$140$1@dont-email.me> (permalink)
References	<76630b90-04ab-4976-b1a0-76868d85ccf5@vy9g2000pbc.googlegroups.com><jo8q4b$sk0$1@dont-email.me> <joh3id$fkg$1@reader1.panix.com><joh5cv$bdv$1@dont-email.me><0.dc8a6b6b69305a2021d3.20120511162446BST.87sjf6wxj5.fsf@bsb.me.uk><jojofb$hvo$1@dont-email.me> <0.b12cce1ec5f25bcfb767.20120511205606BST.8762c2wkyx.fsf@bsb.me.uk>

Show all headers | View raw

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.b12cce1ec5f25bcfb767.20120511205606BST.8762c2wkyx.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> You've got it wrong; you need more arbitrariness to increase the number 
>> of
>> levels.

> Most of my post did try to explain why it's not arbitrary!

You tried to justify why every new operator seems to need it's own 
precedence level. But OK:

> Because of the strong mathematical the connection between &/| and */+ it
> is natural to separate these pairs by precedence.

It also makes it natural to group them together.

> Once you have 11, it seems to me you may as well have 15.

Now you seem to be saying there are so many, that you need to keep a table 
to hand anyway, so it doesn't matter how many levels there are!

>  Putting ^ in
> with, say, |; or putting the shift operators in with * would probably be
> as confusing as giving them their own level.

Shift operators effectively multiply and divide; so why *not* lump them with 
* and /? As it as, some are obliged to use parentheses as they will not know 
off-hand where they actually are in the hierarchy.

>  And separating == and !=
> from < and friends has strong arguments in its favour, which there is no
> reason to ignore once you already have so many levels.

Again, adding levels for it's own sake. And, should be == be higher then >, 
or the other way? And, what are the arguments for not having the same level 
for all of them? I can't see a reason to favour (a==b)<c over a==(b<c) or 
vice versa.

>> The difference between add/subtract, and multiple/divide, most people 
>> know
>> about. That's two. There's a few more levels ...

> I don't want = and , to share precedence with any of these.

Well, OK, in C, "=" is classed as an operator, although a low priority one. 
So actually when you take out the obvious ones, such as "=" and ".", there's 
a bit less than 15 to remember. But still too many..

>> (In a UK general discussion forum, the value of 48÷2(9+3) was recently
>> discussed. After 2500 posts, there was still no agreement!

> I can't see what the number of precedence levels has to do with this
> example.  The only possible ambiguity (as evidenced by the two answers
> you give) is about associativity, not precedence.

That's true; I tend to lump the two together. Ultimately what's being 
decided is order of evaluation**. The point was, the general public seem to 
have a real problem with this stuff; I can fare a bit better, but still have 
trouble remembering beyond about six levels (and that only because they are 
in two groups: arithmetic, and compare/logical).

Did the designers of C actually seek to minimise precedence levels? Did they 
think that having many of them would be better than having too few? Having 
too few levels means extra parentheses. Having too many also means extra 
parentheses when you can't remember the priorities!

(** And yes I know the right terminology is a bit different. Sometimes there 
is a choice of evaluation order without affecting the result.)

-- 
Bartc

Thread

Operator precedence. somenath <somenathpal@gmail.com> - 2012-05-06 20:10 -0700
  Re: Operator precedence. somenath <somenathpal@gmail.com> - 2012-05-06 20:23 -0700
  Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-06 23:57 -0400
  Re: Operator precedence. Kaz Kylheku <kaz@kylheku.com> - 2012-05-07 03:59 +0000
  Re: Operator precedence. pete <pfiland@mindspring.com> - 2012-05-07 05:48 -0400
    Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 07:52 -0400
      Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-07 13:18 +0100
        Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 09:08 -0400
          Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-07 14:36 +0100
            Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-07 13:29 -0400
      Re: Operator precedence. pete <pfiland@mindspring.com> - 2012-05-07 11:24 -0400
  Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-07 16:35 +0100
    Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-10 19:05 +0000
      Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-10 20:35 +0100
        Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 09:25 -0400
          Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 16:42 +0100
            Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 12:28 -0400
              Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 18:42 +0100
                Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 15:18 -0400
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:52 +0100
                Re: Operator precedence. James Kuyper <jameskuyper@verizon.net> - 2012-05-11 18:39 -0400
                Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 19:20 +0000
                Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 19:28 +0000
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:28 +0100
                Re: Operator precedence. Ike Naar <ike@sverige.freeshell.org> - 2012-05-11 21:45 +0000
              Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-12 12:11 -0700
            Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 17:37 +0100
        Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 16:24 +0100
          Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 20:14 +0100
            Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-11 20:56 +0100
              Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-11 22:21 +0100
                Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 00:05 +0100
          Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-11 22:46 +0000
            Re: Operator precedence. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-05-12 00:17 +0100
              Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-12 19:35 +0000
                Re: Operator precedence. "BartC" <bc@freeuk.com> - 2012-05-12 22:39 +0100
            Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-12 16:07 -0700
              Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-13 19:08 +0000
                Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-13 13:17 -0700
                Re: Operator precedence. jgk@panix.com (Joe keane) - 2012-05-14 21:06 +0000
                Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-14 20:42 -0700
                Re: Operator precedence. Kaz Kylheku <kaz@kylheku.com> - 2012-05-13 23:20 +0000
      Re: Operator precedence. Keith Thompson <kst-u@mib.org> - 2012-05-10 15:24 -0700

csiph-web