Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399456 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-27 19:53 +0200 |
| Last post | 2026-05-30 11:18 +0200 |
| Articles | 20 on this page of 178 — 18 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-03 22:30 +0000
Re: Parentheses Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-03 16:24 -0700
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 02:03 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 01:12 +0100
Re: Parentheses antispam@fricas.org (Waldek Hebisch) - 2026-06-04 01:58 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:11 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 22:14 +0100 |
| Message-ID | <10vcvjn$dhga$2@dont-email.me> |
| In reply to | #399512 |
On 29/05/2026 21:00, Janis Papanagnou wrote: > On 2026-05-29 20:09, Bart wrote: >> You actually said this: > > You continue your trollish stance to cherry-pick words without > understanding or trying to understand what's been expressed. > > The insight appears to me that you're taking communication in a > similar way as you "design" your languages; focusing on personal > *syntax* preferences instead of the more important *semantics*. > > Despite we're talking in your native language English is my second language, technically. > (and not mine) you > obvious completely miss or deliberately ignore that there's a > difference between "it makes perfectly sense" and "it's perfect". > (I said the former, you put the latter in my mouth. It's paraphrasing. Here is your quote again: > (The point is that - with the exception of & ^ | - the ranking > makes perfect[ly] sense and should be easily usable without doubt > by a concept-knowing programmer." I've isolated the 'ly' as that is incorrect grammar and have ignored it. I don't know what impression someone can take from this other than you think it's all dandy apart from that one exception. So, what am I missing? Did you mean the rest is all fine, considering this is C, but it is not perfect? In that case, what /would/ be perfect in your view? Assume a fantasy language where anything is possible. > >> What I would say is that operator precedences are in "C" > >> "sensibly and appropriately defined, modulo the bit-ops". > you're still playing your stupid game; you ignored that. I suggest > to try to map this statement to either of the above two statements, > the one I said and the one you (wrongly) attributed, and see which > one fits. (Hint: the former.) OK, so why don't you list all the things you think are amiss with C operator precedences. Apart from that exception.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-29 12:09 -0700 |
| Message-ID | <10vcoa3$buur$1@kst.eternal-september.org> |
| In reply to | #399500 |
Bart <bc@freeuk.com> writes:
> On 29/05/2026 16:59, Scott Lurndal wrote:
[...]
>> Why bother? C isn't ever going to change operator precedence
>> just to make Bart happy.
>
> It would make me happy just for someone to admit there are
> problems.
There are problems.
Are you happy now?
I didn't think so.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 17:05 +0100 |
| Message-ID | <10vcdh2$82tr$1@dont-email.me> |
| In reply to | #399496 |
On 29/05/2026 16:15, Janis Papanagnou wrote: > On 2026-05-29 15:22, Bart wrote: >> On 29/05/2026 13:46, Janis Papanagnou wrote: >>> On 2026-05-29 13:19, Bart wrote: >>>> On 29/05/2026 09:02, Janis Papanagnou wrote: >>>>> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: >>>>>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: > [...] >>> [...] >>> >>> The "confusions" you listed - not worth quoting - are your personal >>> problem. The precedence of assignments and related operations and >>> their evaluation order are clear, reasonable, and they can be found >>> that way in many existing languages. (Some of your listed "problems" >>> have been answered here already in the past - I wonder whether it's >>> worth replying to you if you don't learn from the answers. You seem >>> to have fun wasting everyone's time.) >>> >>> [...] >> >> I noticed that you didn't answer my questions. > > Yes, because, as experience shows, it's obviously a waste of time! It can go both ways. You always exasperatingly insist that there is only one thing wrong with C's precedence rules, and I think you said once that they are are otherwise perfect. And yet there endless examples on forums of people saying they are confusing.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 18:34 +0200 |
| Message-ID | <10vcf6g$3uus7$5@dont-email.me> |
| In reply to | #399498 |
On 2026-05-29 18:05, Bart wrote: > On 29/05/2026 16:15, Janis Papanagnou wrote: >> On 2026-05-29 15:22, Bart wrote: >>> On 29/05/2026 13:46, Janis Papanagnou wrote: >>>> On 2026-05-29 13:19, Bart wrote: >>>>> On 29/05/2026 09:02, Janis Papanagnou wrote: >>>>>> On 2026-05-29 01:54, Lawrence D’Oliveiro wrote: >>>>>>> On Thu, 28 May 2026 14:07:45 -0500, BGB wrote: >> [...] >>>> [...] >>>> >>>> The "confusions" you listed - not worth quoting - are your personal >>>> problem. The precedence of assignments and related operations and >>>> their evaluation order are clear, reasonable, and they can be found >>>> that way in many existing languages. (Some of your listed "problems" >>>> have been answered here already in the past - I wonder whether it's >>>> worth replying to you if you don't learn from the answers. You seem >>>> to have fun wasting everyone's time.) >>>> >>>> [...] >>> >>> I noticed that you didn't answer my questions. >> >> Yes, because, as experience shows, it's obviously a waste of time! (My reply on your previous examples just posted.) > > It can go both ways. > > You always exasperatingly insist that there is only one thing wrong with > C's precedence rules, and I think you said once that they are are > otherwise perfect. It is true and acknowledged even by the designers of the C-language that there's a misplaced group in the table; the three bit-ops. I don't think that "perfect" is a fitting word, but it's otherwise (modulo bit-ops) surely an *appropriate* sensible choice they made. The less important options might be defined in one way or another; and various language designers have taken different ways how many groups they define, or how boolean and numeric operators relate in precedence, for example. > And yet there endless examples on forums of people > saying they are confusing. Your endless complaint-tirades may have made me miss these dubious "endless examples on forums of people saying they are confusing". If you are active on these forums I'd at least not be astonished if you'd contributed to anyone's confusion given how you behave here even on simple and clear facts about "C". Janis
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2026-05-29 19:29 +0200 |
| Message-ID | <10vcidf$20dq$1@news.gegeweb.eu> |
| In reply to | #399494 |
On 5/29/26 15:22, Bart wrote:
> Something you might do when you have time (as I'm busy), is to analyse
> the expressions in some C codebases, and isolate those where removal of
> parentheses that group terms, would result in exactly the same shape of
> expressions, and are therefore redundant.
This is a strange exercice. When I write complex expression,
I sometime use redondant parenthesis for the clarity of
my intentions about this computation. I'm thinking that
those extra (()) are a sort of in-line comments.
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 18:53 +0100 |
| Message-ID | <10vcjrb$aquo$1@dont-email.me> |
| In reply to | #399503 |
On 29/05/2026 18:29, tTh wrote: > On 5/29/26 15:22, Bart wrote: > >> Something you might do when you have time (as I'm busy), is to analyse >> the expressions in some C codebases, and isolate those where removal >> of parentheses that group terms, would result in exactly the same >> shape of expressions, and are therefore redundant. > > This is a strange exercice. When I write complex expression, > I sometime use redondant parenthesis for the clarity of > my intentions about this computation. I'm thinking that > those extra (()) are a sort of in-line comments. > Sure, but some here like to say that such expressions, if they still work without parentheses, are unambiguous anyway. They forget that people aren't compilers. And then the point becomes, if you always add the parentheses, what was the point of having that particular precedence level?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-29 12:28 -0700 |
| Message-ID | <10vcpci$buur$2@kst.eternal-september.org> |
| In reply to | #399504 |
Bart <bc@freeuk.com> writes:
> On 29/05/2026 18:29, tTh wrote:
>> On 5/29/26 15:22, Bart wrote:
>>> Something you might do when you have time (as I'm busy), is to
>>> analyse the expressions in some C codebases, and isolate those
>>> where removal of parentheses that group terms, would result in
>>> exactly the same shape of expressions, and are therefore redundant.
>> This is a strange exercice. When I write complex expression,
>> I sometime use redondant parenthesis for the clarity of
>> my intentions about this computation. I'm thinking that
>> those extra (()) are a sort of in-line comments.
>>
>
> Sure, but some here like to say that such expressions, if they still
> work without parentheses, are unambiguous anyway.
>
> They forget that people aren't compilers.
To state the obvious, complicated expressions that rely on C's more
obscure precedence can be confusing to some human readers, but are
unambiguous to compilers. Most of us will add parentheses that
are not strictly necessary to the compiler, but that are helpful to
human readers. There is no universal agreement on which parentheses
are helpful or necessary and which are not, and there never will be.
> And then the point becomes, if you always add the parentheses, what
> was the point of having that particular precedence level?
You're asking why C is designed the way it is. We could waste a
great deal of time and effort answering that for you. There are
numerous documents about the design and history of C, and of
its ancestor languages. I could provide you with links.
What if I did the research and presented you with an explanation for
all of C's precedence levels? What if I could tell you exactly what
Ken Thompson had in mind when he specified the expression syntax
for B, and exactly what Dennis Ritchie had in mind when he based C
on Thompson's work? What if you clearly and completely understood
why C's expression syntax is the way it is, including parts of the
syntax that Ritchie himself regretted, including parts that you
obviously could have done better?
What then? Would an answer to your question help you? Would it
satisfy you? Would you even thank me for the effort if I did that?
Or would you just keep complaining about something that cannot be
changed without breaking existing code? Would you talk about C's
expression syntax in a way intended to help others understand it,
or would you continue to post contrived examples that make it appear
as confusing as possible?
Bart, what do you want?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 20:49 +0100 |
| Message-ID | <10vcqjc$con8$1@dont-email.me> |
| In reply to | #399509 |
On 29/05/2026 20:28, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > or would you continue to post contrived examples that make it appear > as confusing as possible? Examples are examples. Do you want me to post one that didn't illustrate an issue? It necessaily has to be contrived. > > Bart, what do you want? > Today I was just replying to this post today that I found annoying: JP: > Unsurprisingly; since exactly *that* was the obvious (and single) > issue with C's precedence definitions. That is, the suggestion, made several times by JP, that there is only one thing wrong.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-29 22:03 +0200 |
| Message-ID | <10vcrdo$3uus8$6@dont-email.me> |
| In reply to | #399510 |
On 2026-05-29 21:49, Bart wrote: > On 29/05/2026 20:28, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: > >> or would you continue to post contrived examples that make it appear >> as confusing as possible? > > Examples are examples. Do you want me to post one that didn't illustrate > an issue? It necessaily has to be contrived. > >> >> Bart, what do you want? >> > > > Today I was just replying to this post today that I found annoying: > > JP: > > Unsurprisingly; since exactly *that* was the obvious (and single) > > issue with C's precedence definitions. > > That is, the suggestion, made several times by JP, that there is only > one thing wrong. The C-precedence rules have one issue. The rest is a sensible choice. (The C-language has more issue, but that was not the topic here.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-29 13:56 -0700 |
| Message-ID | <10vcui4$buur$3@kst.eternal-september.org> |
| In reply to | #399510 |
Bart <bc@freeuk.com> writes:
> On 29/05/2026 20:28, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> or would you continue to post contrived examples that make it appear
>> as confusing as possible?
>
> Examples are examples. Do you want me to post one that didn't
> illustrate an issue? It necessaily has to be contrived.
>
>> Bart, what do you want?
>>
>
>
> Today I was just replying to this post today that I found annoying:
>
> JP:
>> Unsurprisingly; since exactly *that* was the obvious (and single)
>> issue with C's precedence definitions.
>
> That is, the suggestion, made several times by JP, that there is only
> one thing wrong.
I note your refusal to address most of what I wrote.
Upthread, you asked a question:
And then the point becomes, if you always add the parentheses, what
was the point of having that particular precedence level?
You've made it clear that you were never interested in an answer.
Please do not waste everyone's time by asking questions when you're
not interested in the answers. Please do not assume that anyone
can tell whether one of your questions is sincere, figurative,
or rhetorical.
Bart, what do you want?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-29 22:54 +0100 |
| Message-ID | <10vd1tu$ekvl$1@dont-email.me> |
| In reply to | #399518 |
On 29/05/2026 21:56, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 29/05/2026 20:28, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>> or would you continue to post contrived examples that make it appear >>> as confusing as possible? >> >> Examples are examples. Do you want me to post one that didn't >> illustrate an issue? It necessaily has to be contrived. >> >>> Bart, what do you want? >>> >> >> >> Today I was just replying to this post today that I found annoying: >> >> JP: >>> Unsurprisingly; since exactly *that* was the obvious (and single) >>> issue with C's precedence definitions. >> >> That is, the suggestion, made several times by JP, that there is only >> one thing wrong. > > I note your refusal to address most of what I wrote. > > Upthread, you asked a question: > > And then the point becomes, if you always add the parentheses, what > was the point of having that particular precedence level? > > You've made it clear that you were never interested in an answer. You said this: "You're asking why C is designed the way it is. We could waste a great deal of time and effort answering that for you. There are numerous documents about the design and history of C, and of its ancestor languages. I could provide you with links." Actually I'm not asking why C is like that. We're already there. I'm saying that there is no value in those extra levels, some people think is, and I'm arging about that. I was replying to tTh. As for my question, what /is/ the point? I'm still waiting! Of course, I want the answer to be that there isn't any point if parentheses will be used anyway. > Bart, what do you want? What answer do you want from me? As I said it was a reply to JP. You didn't need to step it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-29 15:52 -0700 |
| Message-ID | <10vd5au$fam9$1@kst.eternal-september.org> |
| In reply to | #399520 |
Bart <bc@freeuk.com> writes:
> On 29/05/2026 21:56, Keith Thompson wrote:
[...]
>> I note your refusal to address most of what I wrote.
>>
>> Upthread, you asked a question:
>>
>> And then the point becomes, if you always add the
>> parentheses, what was the point of having that particular
>> precedence level?
>>
>> You've made it clear that you were never interested in an answer.
>
> You said this:
>
> "You're asking why C is designed the way it is. We could waste a
> great deal of time and effort answering that for you. There are
> numerous documents about the design and history of C, and of
> its ancestor languages. I could provide you with links."
>
> Actually I'm not asking why C is like that. We're already there.
Then your question was unclear. The only reasonable interpretation
I could see for your question, quoted above, is that you wanted
to know why Dennis Ritchie chose the specific precedence rules
that he chose when he was designing the C language in the 1970s.
(The precedence rules have been stable since then.)
What did you mean to ask? Was your question meant to be rhetorical?
Did you just mean to let us know that you don't like C's precedence
rules? I think we all knew that.
[...]
> As for my question, what /is/ the point? I'm still waiting!
I see that (what *is* the point) as a different question from what
you wrote earlier (what *was* the point).
The rules are what they are.
I honestly don't have any strong opinions about what the rules
*should* be.
> Of course, I want the answer to be that there isn't any point if
> parentheses will be used anyway.
Parentheses are not always used. Some programmers know the
precedence rules well enough, and expect their readers to know them
well enough, that they don't need to add parentheses. I don't bother
with parentheses in `a = b + c` or `a + b * c`. Others might not
bother with parentheses in more obscure cases where I would use them.
C compilers must implement the rules as specified in the standard.
Future editions of the standard are unlikely to reorder the
precedence rules, since that would quietly break existing code.
C programmers may or may not choose to remember and/or take advantage
of all the precedence rules. I haven't memorized all of them myself.
[snip]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-29 20:31 -0400 |
| Message-ID | <10vdb5m$gvqj$1@dont-email.me> |
| In reply to | #399521 |
On 2026-05-29 18:52, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: ... >> Of course, I want the answer to be that there isn't any point if >> parentheses will be used anyway. The answer, of course, is that the condition of your "if" clause is not true. In the overwhelming majority of the cases, people do not use parentheses to clarify the order of evaluation that is guaranteed by C's grammar rules. They only use them in the cases where they feel that there's a significant chance of confusion. Of course, that depends upon your audience. If I was required to write code in such a way that you would have trouble misunderstanding it, I'd write a = m*x + b; as a = ((m*x)+b); I internalized C's grammar rules a long time ago (which causes problems on the rare occasions when they've changed them). The main exception are the bit-wise operators which are well known as having the wrong precedence - but I've seldom needed to use those operators. As a result, I seldom have any confusion as to the order of evaluation, which makes it very hard for me to realize that it might be a good idea to put in some redundant parentheses to clarify that order for other people. That means that some of my code is probably more cryptic than it should be.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-30 02:03 +0100 |
| Message-ID | <10vdd1r$gtcd$2@dont-email.me> |
| In reply to | #399525 |
On 30/05/2026 01:31, James Kuyper wrote:
> On 2026-05-29 18:52, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
> ...
>>> Of course, I want the answer to be that there isn't any point if
>>> parentheses will be used anyway.
>
> The answer, of course, is that the condition of your "if" clause is not
> true. In the overwhelming majority of the cases, people do not use
> parentheses to clarify the order of evaluation that is guaranteed by C's
> grammar rules. They only use them in the cases where they feel that
> there's a significant chance of confusion.
Those are the cases we're talking about! That is:
<< >> & | ^
Maybe add == != and < <= >= > is someone wants to take advantage of
their different levels, but I guess 99% wouldn't even know about what.
Most of the rest, there tends to be agreement across languages:
school arithmetic group - comparisons - logical and/or
I haven't included ?: as that's too weird.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-29 19:02 -0700 |
| Message-ID | <10vdgfs$i57l$1@kst.eternal-september.org> |
| In reply to | #399526 |
Bart <bc@freeuk.com> writes:
> On 30/05/2026 01:31, James Kuyper wrote:
>> On 2026-05-29 18:52, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>> ...
>>>> Of course, I want the answer to be that there isn't any point if
>>>> parentheses will be used anyway.
>>
>> The answer, of course, is that the condition of your "if" clause is
>> not true. In the overwhelming majority of the cases, people do not
>> use parentheses to clarify the order of evaluation that is guaranteed
>> by C's grammar rules. They only use them in the cases where they feel
>> that there's a significant chance of confusion.
>
> Those are the cases we're talking about! That is:
>
> << >> & | ^
>
> Maybe add == != and < <= >= > is someone wants to take advantage of
> their different levels, but I guess 99% wouldn't even know about what.
>
> Most of the rest, there tends to be agreement across languages:
>
> school arithmetic group - comparisons - logical and/or
>
> I haven't included ?: as that's too weird.
So what is your question? I had thought that you meant to ask why
Ritchie defined the precedences that way, but apparently that's
not what you meant.
Do you even have a question? Is there anything anyone could tell
you that you don't think you already know?
If you have a question, can you restate it in unambiguous terms?
If not, what are we talking about?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-30 12:12 +0100 |
| Message-ID | <10vegmt$ps93$2@dont-email.me> |
| In reply to | #399527 |
On 30/05/2026 03:02, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 30/05/2026 01:31, James Kuyper wrote: >>> On 2026-05-29 18:52, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>> ... >>>>> Of course, I want the answer to be that there isn't any point if >>>>> parentheses will be used anyway. >>> >>> The answer, of course, is that the condition of your "if" clause is >>> not true. In the overwhelming majority of the cases, people do not >>> use parentheses to clarify the order of evaluation that is guaranteed >>> by C's grammar rules. They only use them in the cases where they feel >>> that there's a significant chance of confusion. >> >> Those are the cases we're talking about! That is: >> >> << >> & | ^ >> >> Maybe add == != and < <= >= > is someone wants to take advantage of >> their different levels, but I guess 99% wouldn't even know about what. >> >> Most of the rest, there tends to be agreement across languages: >> >> school arithmetic group - comparisons - logical and/or >> >> I haven't included ?: as that's too weird. > > So what is your question? I had thought that you meant to ask why > Ritchie defined the precedences that way, but apparently that's > not what you meant. You seem to have a problem with context. I was replying to JK who was replying to a quote of mine from within one of your posts (maybe he's killfiled me so couldn't respond directly). There was no question posted. He suggested that most of the time, parentheses are not used and gave examples using * and +. My original remarks were about the widespread use of parentheses to clarify the grouping of operators with the more obscure priorities, and my reply addressed that. See also the examples I posted a few minutes ago involving >> & and ^. That is, if you are interested in my point, which I doubt. You seem more intent on some personal campaign.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-30 12:29 +0000 |
| Message-ID | <10vel6r$l1g$1@reader1.panix.com> |
| In reply to | #399520 |
In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 29/05/2026 21:56, Keith Thompson wrote: >> [snip] >> Upthread, you asked a question: >> >> And then the point becomes, if you always add the parentheses, what >> was the point of having that particular precedence level? >> >> You've made it clear that you were never interested in an answer. > >You said this: > >"You're asking why C is designed the way it is. We could waste a >great deal of time and effort answering that for you. There are >numerous documents about the design and history of C, and of >its ancestor languages. I could provide you with links." > >Actually I'm not asking why C is like that. We're already there. > >I'm saying that there is no value in those extra levels, some people >think is, and I'm arging about that. I was replying to tTh. > >As for my question, what /is/ the point? I'm still waiting! To clarify: the question is, what is the point of those levels? How is that different from asking "why C is like that"? >Of course, I want the answer to be that there isn't any point if >parentheses will be used anyway. There is a point, but it is history. That is, the "point" is of those precedence levels is the history and evolution of the language. In PL/1 and early C, `|` and `&` were logical operators. The short-circuiting `||` and `&&` came later, but the usage low precedence for `|` and `&` was already baked in. That's the point: the precedence reflects the original use as boolean operators, not how things evolved for use almost purely as bitwise operators. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-30 13:56 +0100 |
| Message-ID | <10vemqf$r5qe$1@dont-email.me> |
| In reply to | #399536 |
On 30/05/2026 13:29, Dan Cross wrote:
> In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>> On 29/05/2026 21:56, Keith Thompson wrote:
>>> [snip]
>>> Upthread, you asked a question:
>>>
>>> And then the point becomes, if you always add the parentheses, what
>>> was the point of having that particular precedence level?
>>>
>>> You've made it clear that you were never interested in an answer.
>>
>> You said this:
>>
>> "You're asking why C is designed the way it is. We could waste a
>> great deal of time and effort answering that for you. There are
>> numerous documents about the design and history of C, and of
>> its ancestor languages. I could provide you with links."
>>
>> Actually I'm not asking why C is like that. We're already there.
>>
>> I'm saying that there is no value in those extra levels, some people
>> think is, and I'm arging about that. I was replying to tTh.
>>
>> As for my question, what /is/ the point? I'm still waiting!
>
> To clarify: the question is, what is the point of those levels?
>
> How is that different from asking "why C is like that"?
My question is actually independent of C or its history.
I accept those levels exist. I was asking do they currently serve a
useful purpose.
If not, people can choose to ignore those them when writing C code, for
example like this where all () are technically superfluous:
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
And they can choose to not adopt them when devising new languages,
however many still do faithfully recreate the same pattern, with a few
notable exceptions such as Go lang.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-30 16:43 -0700 |
| Message-ID | <10vfsmo$16jap$1@kst.eternal-september.org> |
| In reply to | #399538 |
Bart <bc@freeuk.com> writes:
> On 30/05/2026 13:29, Dan Cross wrote:
>> In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>> On 29/05/2026 21:56, Keith Thompson wrote:
>>>> [snip]
>>>> Upthread, you asked a question:
>>>>
>>>> And then the point becomes, if you always add the parentheses, what
>>>> was the point of having that particular precedence level?
>>>>
>>>> You've made it clear that you were never interested in an answer.
>>>
>>> You said this:
>>>
>>> "You're asking why C is designed the way it is. We could waste a
>>> great deal of time and effort answering that for you. There are
>>> numerous documents about the design and history of C, and of
>>> its ancestor languages. I could provide you with links."
>>>
>>> Actually I'm not asking why C is like that. We're already there.
>>>
>>> I'm saying that there is no value in those extra levels, some people
>>> think is, and I'm arging about that. I was replying to tTh.
>>>
>>> As for my question, what /is/ the point? I'm still waiting!
>> To clarify: the question is, what is the point of those levels?
>> How is that different from asking "why C is like that"?
>
> My question is actually independent of C or its history.
>
> I accept those levels exist. I was asking do they currently serve a
> useful purpose.
That's very different from your original question, which is quoted
above. Your original question, with its use of the past tense,
seemed clearly (to me) to be about how C was originally designed.
I don't have a straightforward yes or no answer to your restated
question.
C's operator precedence rules are complicated and arguably flawed.
They could have been defined differently. A simpler set of rules,
with fewer levels, *might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.
Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.
Even having multiplication bind more tightly than addition is
fundamentally an arbitrary choice (though one that's almost
universally recognized, even outside the context of programming
languages).
Of course all C implementations must implement the expression
syntax as it's defined by the standard, and any changes in future
editions of the standard would be impractical. As a programmer,
I don't have to be as strict; I can add parentheses when writing
code, and I can look up the rules as needed when reading code.
> If not, people can choose to ignore those them when writing C code,
> for example like this where all () are technically superfluous:
>
> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
Yes, they can, and I personally tend to agree that they should.
> And they can choose to not adopt them when devising new languages,
> however many still do faithfully recreate the same pattern, with a few
> notable exceptions such as Go lang.
When designing a new language, there are real advantages in strictly
imitating C's rules, just because so many programmers are familiar
with them. (I would have been silly for C++ or Objective-C to
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's. It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-31 03:37 +0200 |
| Message-ID | <10vg3de$3uus8$9@dont-email.me> |
| In reply to | #399541 |
On 2026-05-31 01:43, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> [...] > [...] > > C's operator precedence rules are complicated and arguably flawed. I'd say that just the (known) flaw makes them (slightly) complicated; so you need to remember that "flaw" (or "inconsistency") to be safe. The rest is completely sensible. And even if one doesn't have a table to look up the precedences they mostly can be derived (presuming one has a feeling for the underlying logic of these things or experiences from other related areas). > They could have been defined differently. A simpler set of rules, > with fewer levels, *might* have been better. I don't have any > concrete suggestions -- nor do I have any strong preferences. > I accept C's rules as they are. I would accept them if they had > been defined differently. > > Nothing about the current rules particularly bothers me. There are > no objective criteria for deciding what the rules *should* be. There are. (What I called above as "derived underlying logic".) Some aspects have already been formulated in this and other threads here. But maybe not obvious to recognize without background in mathematics, logic, or CS. > Even having multiplication bind more tightly than addition is > fundamentally an arbitrary choice (Now opinions are getting really strange; in the above stated sense.) > (though one that's almost > universally recognized, even outside the context of programming > languages). > > [...] > >> If not, people can choose to ignore those them when writing C code, >> for example like this where all () are technically superfluous: >> >> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)]; > > Yes, they can, and I personally tend to agree that they should. The more complex the expressions are the more structure they need. IMO, the parenthesis above make precedence clear (if unknown!), but are not contributing to readability. It would have made more sense to separate the sub-expression within the [...] in an own object to enhance readability and to more easily understand what's going on. To emphasize; not the precedences are the problem above, but the complexity of the expression in connexion with lack of structuring. >> [...] > > When designing a new language, there are real advantages in strictly > imitating C's rules, just because so many programmers are familiar > with them. Huh? - How that? - Are you saying here that practically only C-like languages are in common use? - But even if so; there's quite some languages with differing precedence rules, not C-based, and without such a flaw like the one being discussed. - When designing a *new* language I'd certainly choose one of the sensible precedence rules, and just without those obvious flaws. (And not use "C" as base, of course.) > (I would have been silly for C++ or Objective-C to > change the precedence rules, even to improve them.) But there > are also real advantages in using precedence rules that are better > (e.g., simpler) than C's. Or - with reference to that flaw - just more consistent. Consistent systems are inherently simpler, in the sense of easier to understand and thus more straightforward to use. A precondition for that is, as said, at least a basic understanding of such things. > It depends on the nature of the language. > It could be an interesting discussion for comp.lang.misc. Janis
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web