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

Groups > comp.lang.c > #20596

Re: Operator precedence.

Show all headers | View raw

On 05/11/2012 11:42 AM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:joj40b$e1t$1@dont-email.me...
>> On 05/10/2012 03:35 PM, BartC wrote:
>>>
>>>
>>> "Joe keane" <jgk@panix.com> wrote in message
> 
>>>>    //
>>>>    FROM TO
>>>>    .EQV. .NEQV.
> 
>>> Well they don't look like C. ...
>>
>> It looks like Fortran to me; I'm not quite sure what he meant by that.
> 
> But what are those funny ones like // and FROM? If // is integer division,
> then why does it need to be different from /?

I've no idea - the last time I did any significant Fortran programming
was 2 decades ago, in VMS Fortran. There have been two or three?
revisions to the Fortran standard since then, including a lot of new
features that make it a very different language. I can't vouch for
whether // and FROM might be two of those new features, but the rest of
list looked like Fortran to me.

> 
>>> ... And I'm not sure why unary ops are included in
>>> that lot. ...
>>
>> I'm not sure why you consider that odd.
>> The precedence of unary operators matters; otherwise *a++ could be
>> either (*a)++ or *(a++), and *a-b could be either *(a-b) or (*a)-b. C
>> gives postfix operators the highest precedence, and unary prefix
>> operators second highest, a distinction that neither his list nor your
>> list addresses. As a result, *a->b is *(a->b), not (*a)->b.
> 
> Unary ops are executed before binary ones, so they shouldn't even be in the
> same list.

This is about hierarchy within the parse tree, not execution order. The
parse tree imposes some constraints on the execution order, but does not
determine it. In the expression *a + ~b * !c, *a need not be evaluated
until after the multiplication.

The features of the grammar that give postfix and prefix operators
higher precedence than the other operators are precisely why they they
go before the other ones.

> ... I'd've thought that was pretty standard (in the same way that you
> don't need to add parentheses to such a list.
> 
> And they would naturally be executed from the inside outwards, so precedence
> doesn't matter there.
> It's only an issue where unary ops can appear on either side of a term, as

Which is precisely why unary ops in C occupy two different precedence
levels, one for postfix and one for prefix operators.

> in your examples. The precedence table in K&R2 suggests that a series of
> unary ops such as op1 op2 A op3 op4 should be calculated as op1(op2((A op4)
> op3)) (with 3 and 4 interchanged). They are confusing.

That's a rather confusing statement. Why did you write "with 3 and 4
interchanged" rather than simply interchanging 3 and 4?

>> ... And whether they are logical or not, too many precedences are
>>> difficult to remember. I tend to use a pattern like this:
>>>
>>> 6 LOGICAL OR
>>> 5 LOGICAL AND
>>> 4 COMPARE/LOGICAL XOR [not sure what this one is doing here]
>>> 3 ADD/SUB/BITWISE AND/OR/XOR
>>> 2 MUL/DIV/MOD/SHIFT
>>> 1 POWER (right-to-left)
>>
>> Where would =, op=, and the comma operator fit into the above scheme?
> 
> If you write the following:
> 
>  A = B op C;
> 
> you would naturally expect B op C, what op happens to be, to be done before 
> the assignment. This suggests assignment should always be done last, and 
> belongs (with assign-op combinations) at the top of my list).

So you need an additional level for that, too. In C, it's not the lowest
precedence, so a , b = c is parsed as a, (b = c), not (a,b)=c (which
would be a constraint violation).

Because C uses grammar productions rather than precedence tables, the
expression a ? b = c : d is not the syntax error (a?b) = (c:d), but is
instead a ? (b=c) : d.

>>> Since C doesn't have a power op, that leaves just 5 levels; only two of
>>> which are needed for normal arithmetic. A bit easier or not?
>>
>> C has 16 levels, but that's partly because it covers 21 operators not
>> present in your list. However, the items covered by your list span 10 of
>> C's precedence levels, so your point still holds.
> 
> 16 is too many (so is 15, the number listed by K&R). Why is == different 
> from <= for example? While <<,>> belong with multiply and divide. And if I 
> read the table properly, then a & b == c & d actually means a & (b==c) & d; 
> that obviously doesn't look right, not for bitwise & anyway.

Not all of the choices made for operator precedence were good ones;
IIRC, Ritchie himself acknowledged that fact. In a new language where
backwards compatibility was not an issue, they should be done
differently. But I don't think that fewer precedence levels is the way
to go.

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

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