Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Operator precedence. |
| Date | 2012-05-11 18:39 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <4FAD9512.7080507@verizon.net> (permalink) |
| References | (5 earlier) <jojc23$m4$1@dont-email.me> <4FAD3E13.7000804@verizon.net> <jojkr0$r88$1@dont-email.me> <4FAD65F5.5040605@verizon.net> <jok1ne$b7p$1@dont-email.me> |
On 05/11/2012 05:52 PM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:4FAD65F5.5040605@verizon.net...
...
>> Yes, if you only consider the unary operators, it's simple. However, the
>> minute you throw in binary operators, the issue does comes up. C deals
>> with that issue by specifying a grammar that gives the postfix operators
>> (both unary and binary)
>
> I'm not too well up on the right terminology, but wouldn't any binary
> operator just be 'infix'?
That's a reasonable point of view, but the C standard calls a[b], a(b),
a.b, a->b, and (a){b} postfix-expressions, even though they're all
binary, and the parts of those expressions that are left after you
remove 'a' and 'b' are considered by the C standard to be postfix
operators. I think that's may be because they are highly asymmetric
operators, so 'b' was considered to be part of the operator, rather than
an operand fully comparable to 'a' itself.
...
> Actually, I've made use of C-style postfix ++,-- operators in my own
> projects. They are parsed as they are in C. (But I don't any special concept
> of precedence, and a much simpler grammar.)
>
>> There are only two unary postfix operators, the other postfix operators
>> are all binary. According to the grammar, a++-- can only be parsed as
>> (a++)--, not as (a--)++. It hardly matters, though: postfix ++ and --
>> both require modifiable lvalues for their left operand (6.5.3.1p2), and
>> neither one has a result which is an lvalue.
>
> (Yes, well, I worry about lvalues in a later pass. My parser only deals
> with 'shape'.)
That's entirely appropriate - constraint violations are to be diagnosed
based upon what you have as a result of parsing; they shouldn't
influence the parsing itself (though people have argued to the contrary
with respect to function-like macros with no arguments). What "shape"
does your language consider a++-- to have?
...
> which fortunately it did. But then, I don't treat "." (or "->") as an
> operator at all; it can't be an operator because the right operand can't be
> a conventional expression.)
The C standard considers it an operator, operating on an expression and
and identifier. Similarly, (a){b} is an operator even though 'a' has to
be a type name, not an expression.
...
> So the issue is really K&R over-simplifying matters in their operator table,
> by including constructs which are not conventional operators in syntax or
> semantics (such as "()" and "[]").
They are operators as far as the C standard is concerned, however
unconventional they might be.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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