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 268 — 20 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: Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:37 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 16:31 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 13:36 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 23:49 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:04 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:10 +0000
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:50 -0700
Re: Constants and undefined behavior Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 10:41 +0200
Re: Constants and undefined behavior Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 10:49 -0700
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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 06:41 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:24 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:22 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 23:56 -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
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 11:37 +0100
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 10:51 +0000
Re: Parentheses Bart <bc@freeuk.com> - 2026-06-04 12:47 +0100
Re: Parentheses Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 14:57 +0200
Re: Parentheses cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 14:31 +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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 02:34 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 12:40 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 14:35 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 14:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:57 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 16:27 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 16:46 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 20:15 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 20:54 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 20:29 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:47 +0100
Famous (hopefully last) words [on this topic] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-05 00:27 +0200
Re: Famous (hopefully last) words [on this topic] Bad Post <invalid@invalid.invalid> - 2026-06-05 01:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 16:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 00:44 +0100
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 17:26 -0700
Re: this girl calls c ugly antispam@fricas.org (Waldek Hebisch) - 2026-06-05 12:58 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-05 14:27 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:47 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 00:53 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 11:04 +0100
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:34 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:44 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-06 07:39 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-04 15:25 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 09:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 12:39 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 15:42 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 16:50 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-05 20:29 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 17:23 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 16:47 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 19:57 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:34 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-04 22:28 +0100
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 21:58 +0000
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-06-04 23:25 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:49 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 19:47 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-04 21:04 +0200
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 19:13 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-05 10:34 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 12:11 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-04 16:33 -0400
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 14:16 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:02 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 18:36 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 02:54 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 05:49 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-05 11:01 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-05 11:53 -0700
Re: this girl calls c ugly Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-04 18:45 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:19 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:31 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-04 20:41 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-04 20:49 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 00:03 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 00:18 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-05 03:02 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-05 14:04 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-06 03:49 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 15:13 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-06 17:53 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-04 11:59 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-04 15:21 +0200
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 06:38 -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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-04 03:58 -0700
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 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 19:19 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vnab9$jqo$1@reader1.panix.com> |
| In reply to | #399639 |
[This is _really_ off-topic now. Follow-up: comp.text] In article <ASCII-20260602180622@ram.dialup.fu-berlin.de>, Stefan Ram <ram@zedat.fu-berlin.de> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) wrote or quoted: >>I used, "monodraw" on the Mac. I can't do that by hand; I am >>not artistically gifted. :-) > > I have been searching for an ASCII-to-ASCII program for a long > time and never found anything impressive. I want to write > a /description/ of my diagram in ASCII and then want to get > my diagram as ASCII. Dot, ditaa, nothing worked. > > The least bad solution I found so far is called /PlantUML/. Personally, I rather like `pic` and `nroff`. Your mileage may vary, however, depending on the complexity of the diagram. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-06-04 00:11 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vqfrh$259o$5@dont-email.me> |
| In reply to | #399639 |
On 2 Jun 2026 17:08:57 GMT, Stefan Ram wrote:
> The least bad solution I found so far is called /PlantUML/.
I, too, came across this while looking at diagram-creation tools
recently.
> "C:\example\java.exe" -jar "C:\example\plantuml.jar" -txt "example.puml"
The Debian package <https://packages.debian.org/trixie/plantuml>
provides a wrapper to make invocation more convenient:
ldo@theon:~> file $(type -p plantuml)
/usr/bin/plantuml: POSIX shell script, ASCII text executable
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 15:39 -0700 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vnm2m$382un$3@kst.eternal-september.org> |
| In reply to | #399633 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <10vmna7$3uus8$13@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>On 2026-06-02 15:05, Dan Cross wrote:
>>> [...]
>>>
>>> ┌──────â”
>>> │ expr │
>>> └──────┘
>>> ╱ │ ╲
>>> ╱ │ ╲
[...]
>>
>>I suppose you have some tool to create those fancy graphics?
>>What are you using for that? - Or is that all hand-crafted?
>
> I used, "monodraw" on the Mac. I can't do that by hand; I am
> not artistically gifted. :-)
For whatever reason, I'm seeing your drawings as gibberish
in articles you post, but as nicely formatted drawings when
they're quoted in replies by others.
https://en.wikipedia.org/wiki/Mojibake
--
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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-03 13:14 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vp9cd$frf$1@reader1.panix.com> |
| In reply to | #399654 |
In article <10vnm2m$382un$3@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <10vmna7$3uus8$13@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>On 2026-06-02 15:05, Dan Cross wrote: >>>> [...] >>>> >>>> ┌──────┠>>>> │ expr │ >>>> └──────┘ >>>> ╱ │ ╲ >>>> ╱ │ ╲ >[...] >>> >>>I suppose you have some tool to create those fancy graphics? >>>What are you using for that? - Or is that all hand-crafted? >> >> I used, "monodraw" on the Mac. I can't do that by hand; I am >> not artistically gifted. :-) > >For whatever reason, I'm seeing your drawings as gibberish >in articles you post, but as nicely formatted drawings when >they're quoted in replies by others. > >https://en.wikipedia.org/wiki/Mojibake Thanks. I customize things to add the appropriate headers. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-02 15:10 +0000 |
| Message-ID | <mnCTR.17470$_BG8.10863@fx24.iad> |
| In reply to | #399623 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> wrote: > >Both expressions above correspond to an AST like: > > ┌───────┐ > │BinOp +│ > └───────┘ > ╱ ╲ > ╱ ╲ > ┌───────┐ ┌───────┐ > │BinOp *│ │Sym `c`│ > └───────┘ └───────┘ > ╱ ╲ > ╱ ╲ > ┌───────┐ ┌───────┐ > │Sym `a`│ │Sym `b`│ > └───────┘ └───────┘ Ah, the dangers of assuming everyone uses UTF-8.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 15:31 +0000 |
| Message-ID | <10vmt11$cev$4@reader1.panix.com> |
| In reply to | #399631 |
In article <mnCTR.17470$_BG8.10863@fx24.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>
>>
>>Both expressions above correspond to an AST like:
>>
>> ┌───────┐
>> │BinOp +│
>> └───────┘
>> ╱ ╲
>> ╱ ╲
>> ┌───────┐ ┌───────┐
>> │BinOp *│ │Sym `c`│
>> └───────┘ └───────┘
>> ╱ ╲
>> ╱ ╲
>> ┌───────┐ ┌───────┐
>> │Sym `a`│ │Sym `b`│
>> └───────┘ └───────┘
>
>Ah, the dangers of assuming everyone uses UTF-8.
Yeah, my bad. Here:
+-------+
|BinOp +|
+-------+
/ \
/ \
+-------+ +-------+
|BinOp *| |Sym `c`|
+-------+ +-------+
/ \
/ \
+-------+ +-------+
|Sym `a`| |Sym `b`|
+-------+ +-------+
(The original looks bad in my newsreader, too.)
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-31 10:15 -0400 |
| Message-ID | <10vhfp5$1iv7k$2@dont-email.me> |
| In reply to | #399548 |
On 2026-05-31 05:49, David Brown wrote: ... > Of course. Parentheses do not affect the generated code unless they > affect the semantics of the expression. (Some people think parentheses > affect the order of evaluation, but that is not the case for most > compilers.) I assume that last sentence is meant to apply only to parentheses which don't change the semantics? Otherwise it seems manifestly false.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-31 16:29 +0200 |
| Message-ID | <10vhgki$1j9hm$1@dont-email.me> |
| In reply to | #399555 |
On 31/05/2026 16:15, James Kuyper wrote: > On 2026-05-31 05:49, David Brown wrote: > ... >> Of course. Parentheses do not affect the generated code unless they >> affect the semantics of the expression. (Some people think parentheses >> affect the order of evaluation, but that is not the case for most >> compilers.) > > I assume that last sentence is meant to apply only to parentheses which > don't change the semantics? Otherwise it seems manifestly false. Yes. I thought I was quite clear in this, given that I wrote almost exactly that in the previous sentence (which you also quoted above).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-31 03:45 -0700 |
| Message-ID | <10vh3gu$1fhs1$1@kst.eternal-september.org> |
| In reply to | #399545 |
Richard Harnden <richard.nospam@gmail.invalid> writes:
> On 31/05/2026 00:43, Keith Thompson wrote:
>> 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.
>
> Can't the compiler easily remove any parens that aren't necessary?
> So - just write complex expressions in a way that a human can most
> easily understand, it makes your intention clear and probable doesn't
> increase the size of the executable.
Compilers generally remove *all* parens, necessary or not.
The output of a compiler is assembly or machine code. You almost
certainly can't tell from the generated code whether the input was,
for example, `a * b + c`, `(a * b) + c`, or `(((a) * (b)) + (c))`.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-31 04:02 -0700 |
| Message-ID | <10vh4g1$1fhs1$2@kst.eternal-september.org> |
| In reply to | #399551 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
>> On 31/05/2026 00:43, Keith Thompson wrote:
>>> 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.
>>
>> Can't the compiler easily remove any parens that aren't necessary?
>> So - just write complex expressions in a way that a human can most
>> easily understand, it makes your intention clear and probable doesn't
>> increase the size of the executable.
>
> Compilers generally remove *all* parens, necessary or not.
> The output of a compiler is assembly or machine code. You almost
> certainly can't tell from the generated code whether the input was,
> for example, `a * b + c`, `(a * b) + c`, or `(((a) * (b)) + (c))`.
I realize I missed part of the point of your question.
Adding parentheses to an expression in a way that yields
an equivalent expression almost certainly will not affect the
generated code. Any parentheses that "restate" the precedence
rules are only for the convenience of human readers.
Ideally, you should always use exactly the right number of
parentheses to optimize readability. But since humans are not
compilers, there is no one way to do that. I would probably
add parentheses to `x == y & z`, assuming I really wanted the
semantics of `(x == y) & z` for some reason, but I would find the
superfluous parentheses in `x + (y * z)` or `x = (y + z)` annoying.
(Almost as annoying as the poor choice of variable names.)
It's possible to have too few parentheses or too many.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 09:04 -0700 |
| Message-ID | <86tsrnefac.fsf@linuxsc.com> |
| In reply to | #399545 |
Richard Harnden <richard.nospam@gmail.invalid> writes: > just write complex expressions in a way that a human can most > easily understand, Unfortunately, (1) different people have different ideas of what writing is most easily understood, and (2) different readers have different notions of which writings are easily understood, and which writings are not so easily understood. To make things worse "easily understood" is not a boolean condition, nor is it necessarily well-ordered -- "most easily understood" isn't always a well-defined quality, even for a given audience. Sadly the idea of writing in a way that is "most easily understood" has resulted in a race to the bottom, where writers are more and more encouraged to take the view that (some) readers are pretty much arbitrarily stupid, with the result that expressions become littered with scads of unnecessary parentheses that actually detract from ease of reading. Good writing is always a balance between too much and too little.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-31 18:11 +0100 |
| Message-ID | <10vhq39$1lpo1$1@dont-email.me> |
| In reply to | #399559 |
On 31/05/2026 17:04, Tim Rentsch wrote: > Richard Harnden <richard.nospam@gmail.invalid> writes: > >> just write complex expressions in a way that a human can most >> easily understand, > > Unfortunately, (1) different people have different ideas of what > writing is most easily understood, and (2) different readers have > different notions of which writings are easily understood, and > which writings are not so easily understood. To make things > worse "easily understood" is not a boolean condition, nor is it > necessarily well-ordered -- "most easily understood" isn't always > a well-defined quality, even for a given audience. > > Sadly the idea of writing in a way that is "most easily understood" > has resulted in a race to the bottom, where writers are more and > more encouraged to take the view that (some) readers are pretty > much arbitrarily stupid, with the result that expressions become > littered with scads of unnecessary parentheses that actually > detract from ease of reading. Good writing is always a balance > between too much and too little. Actual examples of too many parentheses? I don't think they are needed for the three main groups (unless you need to override the normal behaviour): * Arithmetic ops that everyone knows * Comparison ops which can be considered a single level (in C there are two, but they are rarely chained) * Logical AND/OR ops Most involved in coding should know the order of these groups and will know that AND takes precedence over OR because that is common. The leaves the following which are not used in the real world and which are diverse across languages: << >> & | ^ There it makes sense to use parentheses to make things clear when any of these appear, but only if there is more than one and they are mixed. I don't think that is particularly onerous to have to write, or too much clutter to read. I wouldn't call anyone stupid for using () in such cases; more pragmatic. There are some odd ones such as "." (not even considered a binary operator in some languages), and assignment, but these also commonly behave the same way across languages. And then there is ?: : a > b ? c : d # (a>b)?c:d a + b ? c : d # (a+b)?c:d The grouping of the first is probably what is intended. But in the second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't know for sure that the author didn't make a mistake or we don't know outselves. Another candidate for parentheses when there are leading or trailing binary ops involved.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-31 19:34 +0000 |
| Message-ID | <10vi2f8$ovl$2@reader1.panix.com> |
| In reply to | #399561 |
In article <10vhq39$1lpo1$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 31/05/2026 17:04, Tim Rentsch wrote: >> Richard Harnden <richard.nospam@gmail.invalid> writes: >> >>> just write complex expressions in a way that a human can most >>> easily understand, >> >> Unfortunately, (1) different people have different ideas of what >> writing is most easily understood, and (2) different readers have >> different notions of which writings are easily understood, and >> which writings are not so easily understood. To make things >> worse "easily understood" is not a boolean condition, nor is it >> necessarily well-ordered -- "most easily understood" isn't always >> a well-defined quality, even for a given audience. >> >> Sadly the idea of writing in a way that is "most easily understood" >> has resulted in a race to the bottom, where writers are more and >> more encouraged to take the view that (some) readers are pretty >> much arbitrarily stupid, with the result that expressions become >> littered with scads of unnecessary parentheses that actually >> detract from ease of reading. Good writing is always a balance >> between too much and too little. > >Actual examples of too many parentheses? I was working on some code in a Unix-like kernel the other day where the original author wrote, `if ((a == 0) && (b == 1))` type expressions. The inner parentheses were totally superfluous. I removed them. As Tim wrote, there's obviously a balance to be struck between excessive verbosity and extreme concision. Over time, programmers working in a language (or a code base) do tend to internalize that some operations are more frequently misunderstood than others, and parenthesize accordingly. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 19:10 -0700 |
| Message-ID | <86zf1fc8oq.fsf@linuxsc.com> |
| In reply to | #399561 |
Bart <bc@freeuk.com> writes: > On 31/05/2026 17:04, Tim Rentsch wrote: > >> Richard Harnden <richard.nospam@gmail.invalid> writes: >> >>> just write complex expressions in a way that a human can most >>> easily understand, >> >> Unfortunately, (1) different people have different ideas of what >> writing is most easily understood, and (2) different readers have >> different notions of which writings are easily understood, and >> which writings are not so easily understood. To make things >> worse "easily understood" is not a boolean condition, nor is it >> necessarily well-ordered -- "most easily understood" isn't always >> a well-defined quality, even for a given audience. >> >> Sadly the idea of writing in a way that is "most easily understood" >> has resulted in a race to the bottom, where writers are more and >> more encouraged to take the view that (some) readers are pretty >> much arbitrarily stupid, with the result that expressions become >> littered with scads of unnecessary parentheses that actually >> detract from ease of reading. Good writing is always a balance >> between too much and too little. > > Actual examples of too many parentheses? The point of my comment is that either too many or too few is a subjective judgment, not an objective one. > And then there is ?: : > > a > b ? c : d # (a>b)?c:d > a + b ? c : d # (a+b)?c:d > > The grouping of the first is probably what is intended. But in the > second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't > know for sure that the author didn't make a mistake or we don't know > outselves. This example is so addlebrained that it's hard to imagine anyone being confused about it. Or that it's worth any expenditure of thought wondering what to do about people who are.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 11:12 +0100 |
| Message-ID | <10vjltg$255kd$1@dont-email.me> |
| In reply to | #399579 |
On 01/06/2026 03:10, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 31/05/2026 17:04, Tim Rentsch wrote:
>>
>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>>
>>>> just write complex expressions in a way that a human can most
>>>> easily understand,
>>>
>>> Unfortunately, (1) different people have different ideas of what
>>> writing is most easily understood, and (2) different readers have
>>> different notions of which writings are easily understood, and
>>> which writings are not so easily understood. To make things
>>> worse "easily understood" is not a boolean condition, nor is it
>>> necessarily well-ordered -- "most easily understood" isn't always
>>> a well-defined quality, even for a given audience.
>>>
>>> Sadly the idea of writing in a way that is "most easily understood"
>>> has resulted in a race to the bottom, where writers are more and
>>> more encouraged to take the view that (some) readers are pretty
>>> much arbitrarily stupid, with the result that expressions become
>>> littered with scads of unnecessary parentheses that actually
>>> detract from ease of reading. Good writing is always a balance
>>> between too much and too little.
>>
>> Actual examples of too many parentheses?
>
> The point of my comment is that either too many or too few is a
> subjective judgment, not an objective one.
My point was that it could be objective, at least for too many. So (a*a)
+ (b*b) would be commonly agreed to have too many, and I was extending
that to other examples in computing.
>> And then there is ?: :
>>
>> a > b ? c : d # (a>b)?c:d
>> a + b ? c : d # (a+b)?c:d
>>
>> The grouping of the first is probably what is intended. But in the
>> second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't
>> know for sure that the author didn't make a mistake or we don't know
>> outselves.
>
> This example is so addlebrained that it's hard to imagine anyone
> being confused about it. Or that it's worth any expenditure of
> thought wondering what to do about people who are.
I don't understand what the problem is with my examples. There can be
ambiguity in the mind of the person looking at such code as to how the
first terms are grouped.
These are more or less real examples, I just simplified the terms. Here
are some from MZLIB:
return (status == MZ_OK) ? MZ_BUF_ERROR : status;
return (pL == pE) ? (l_len < r_len) : (l < r);
sym = (match_dist < 512) ? s0 : s1;
return ((pState->m_last_status == TINFL_STATUS_DONE) &&
(!pState->m_dict_avail)) ? MZ_STREAM_END : MZ_OK;
I believe that in the first three, all parentheses are superflous, but
they are used anyway. Why is that?
(My preferences for ?: are that the whole thing is syntax, outside of
the precedence scheme, and that it has mandatory parentheses. That
second line would then look like this:
return (pL == pE ? l_len < r_len : l < r);
There are fewer parentheses in all, and less potential confusion. You
can even have assignments in each branch; they will not interfere with ?:.)
As for the last one, I haven't figured it out yet. But simplifying the
terms:
return ((a == b) && (!c)) ? d : e;
then the same applies: this could be:
return a == b && !c ? d : e;
However, I had to confirm this by comparing the ASTs for both.
I'd say that MZLIB is doing the right thing by not being too clever.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 12:36 +0200 |
| Message-ID | <10vjnbn$259m4$1@dont-email.me> |
| In reply to | #399585 |
On 01/06/2026 12:12, Bart wrote: > On 01/06/2026 03:10, Tim Rentsch wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 31/05/2026 17:04, Tim Rentsch wrote: >>> >>>> Richard Harnden <richard.nospam@gmail.invalid> writes: >>>> >>>>> just write complex expressions in a way that a human can most >>>>> easily understand, >>>> >>>> Unfortunately, (1) different people have different ideas of what >>>> writing is most easily understood, and (2) different readers have >>>> different notions of which writings are easily understood, and >>>> which writings are not so easily understood. To make things >>>> worse "easily understood" is not a boolean condition, nor is it >>>> necessarily well-ordered -- "most easily understood" isn't always >>>> a well-defined quality, even for a given audience. >>>> >>>> Sadly the idea of writing in a way that is "most easily understood" >>>> has resulted in a race to the bottom, where writers are more and >>>> more encouraged to take the view that (some) readers are pretty >>>> much arbitrarily stupid, with the result that expressions become >>>> littered with scads of unnecessary parentheses that actually >>>> detract from ease of reading. Good writing is always a balance >>>> between too much and too little. >>> >>> Actual examples of too many parentheses? >> >> The point of my comment is that either too many or too few is a >> subjective judgment, not an objective one. > > My point was that it could be objective, at least for too many. So (a*a) > + (b*b) would be commonly agreed to have too many, and I was extending > that to other examples in computing. > No, it is all still subjective. But the more levels of parentheses, the more consensus you are likely to get on the subjective opinions. To be "objective", you would have to have some kind of measure, with statistically significant results. If someone were to conduct a survey and measure the accuracy and thinking time for people to understand expressions written in different ways with different levels of parentheses, then there would be a basis for calling things "objective".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 14:26 -0700 |
| Message-ID | <10vktel$2glfs$1@kst.eternal-september.org> |
| In reply to | #399585 |
Bart <bc@freeuk.com> writes:
[...]
> These are more or less real examples, I just simplified the
> terms. Here are some from MZLIB:
>
> return (status == MZ_OK) ? MZ_BUF_ERROR : status;
>
> return (pL == pE) ? (l_len < r_len) : (l < r);
>
> sym = (match_dist < 512) ? s0 : s1;
>
> return ((pState->m_last_status == TINFL_STATUS_DONE) &&
> (!pState->m_dict_avail)) ? MZ_STREAM_END : MZ_OK;
>
> I believe that in the first three, all parentheses are superflous, but
> they are used anyway. Why is that?
Obviously it's because the author of the code thought it was
clearer with the parentheses (or was working under a coding standard
written by someone who thought so). I don't think there are any
deeper conclusions to be drawn. I would have written most of them
differently, but it's not a big deal.
> (My preferences for ?: are that the whole thing is syntax, outside of
> the precedence scheme, and that it has mandatory parentheses. That
> second line would then look like this:
>
> return (pL == pE ? l_len < r_len : l < r);
>
> There are fewer parentheses in all, and less potential confusion. You
> can even have assignments in each branch; they will not interfere with
> ?:.)
But the precedence scheme *is* syntax. If you prefer to think of ?:
as something other than an operator, something that that doesn't
follow the same set of rules as other operators, and if that works
for you, then that's fine. But then how do you know that
return (pL == pE ? l_len < r_len : l < r);
means
return ((pL == pE) ? (l_len < r_len) : l < r);
and not
return (pL == (pE ? l_len < r_len : l < r));
?
I know that because I know that ?: is an operator that binds more
loosely than "==".
In any case, however you think about ?:, it's clear that
"pL == pE ? l_len < r_len : l < r" is an expression, and "return"
*is* outside of the precedence scheme. The outer parentheses are
superfluous but harmless. (Personally, I dislike parenthesizing
the expression in a return statement.)
[...]
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-04 02:34 -0700 |
| Message-ID | <86a4tad4xo.fsf@linuxsc.com> |
| In reply to | #399585 |
Bart <bc@freeuk.com> writes:
> On 01/06/2026 03:10, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> On 31/05/2026 17:04, Tim Rentsch wrote:
>>>
>>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>>>
>>>>> just write complex expressions in a way that a human can most
>>>>> easily understand,
>>>>
>>>> Unfortunately, (1) different people have different ideas of what
>>>> writing is most easily understood, and (2) different readers have
>>>> different notions of which writings are easily understood, and
>>>> which writings are not so easily understood. To make things
>>>> worse "easily understood" is not a boolean condition, nor is it
>>>> necessarily well-ordered -- "most easily understood" isn't always
>>>> a well-defined quality, even for a given audience.
>>>>
>>>> Sadly the idea of writing in a way that is "most easily understood"
>>>> has resulted in a race to the bottom, where writers are more and
>>>> more encouraged to take the view that (some) readers are pretty
>>>> much arbitrarily stupid, with the result that expressions become
>>>> littered with scads of unnecessary parentheses that actually
>>>> detract from ease of reading. Good writing is always a balance
>>>> between too much and too little.
>>>
>>> Actual examples of too many parentheses?
>>
>> The point of my comment is that either too many or too few is a
>> subjective judgment, not an objective one.
>
> My point was that it could be objective, at least for too many. So
> (a*a) + (b*b) would be commonly agreed to have too many, [...]
Apparently you misunderstand what is meant by the word objective.
An objective statement is one that is independent of personal
assessment, even collective personal assessment. Reaching consensus
on a question doesn't make the common view an objective one -- just
a commonly held one. Saying the Sun rises in the East is an
objective statement. Saying the temperature is too hot in the month
of September is not an objective statement, even if most people
think so.
>>> And then there is ?: :
>>>
>>> a > b ? c : d # (a>b)?c:d
>>> a + b ? c : d # (a+b)?c:d
>>>
>>> The grouping of the first is probably what is intended. But in the
>>> second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't
>>> know for sure that the author didn't make a mistake or we don't know
>>> outselves.
>>
>> This example is so addlebrained that it's hard to imagine anyone
>> being confused about it. Or that it's worth any expenditure of
>> thought wondering what to do about people who are.
>
> I don't understand what the problem is with my examples.
Here is a story from the earliest weeks of all of the time I have
been programming. In one of the first few programs I ever wrote
(and perhaps even the very first one), I had a statement like so:
x = alpha/beta*gamma
Of course the names here are made up, I don't remember the actual
names used. When x was printed out, it gave a value that was
much different from what I expected. What had happened was I had
unconsciously assumed, reasoning by analogy with written
mathematics, that the statement would be interpreted as
alpha
x = ------------
beta*gamma
After getting the program output back, and seeing the unexpected
result, someone explained to me that the statement was interpreted
as
x = (alpha/beta)*gamma
because that was how the language worked. Of course I was surprised
but I learned the rule and after that had no further problems with
how to read such expressions.
> There can be ambiguity in the mind of the person looking at such
> code as to how the first terms are grouped.
This statement illustrates the problem with examples that you give.
Not only is the presumed reader sort of arbitrarily naive, he or she
is apparently incapable of learning. Everyone who has ever learned
to program has had an experience of a program doing something other
than what was expected, because of a misunderstanding about how the
language works. When that happens, most people simply learn about
their misunderstanding and correct it. The readers in your examples
are like people who started programming after developing Alzheimer's
disease (and no offense meant to anyone afflicted with Alzheimer's).
Maybe there are such people, whether or not caused by a medical
condition, but it doesn't match most programmers' experience, and in
any case is not worth worrying about. If someone can't understand
the rules of the road they shouldn't be behind the wheel of a car.
If someone really can't learn the rules of expression syntax for the
language they are using, they should be advised to try a different
language, or perhaps give up programming altogether. It's silly to
worry about something that 999 people out of a 1000 (and the actual
numbers are undoubtedly much higher) are able to navigate without
difficulty. Yet the examples you give insist on focusing on the few
hopeless individuals. It shouldn't be a surprise that most people
don't share your concerns.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-04 12:40 +0100 |
| Message-ID | <10vro7t$bjmf$1@dont-email.me> |
| In reply to | #399673 |
On 04/06/2026 10:34, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>> My point was that it could be objective, at least for too many. So
>> (a*a) + (b*b) would be commonly agreed to have too many, [...]
>
> Apparently you misunderstand what is meant by the word objective.
> An objective statement is one that is independent of personal
> assessment, even collective personal assessment.
I don't know of any infix PL syntax where 'a*a + b*b', as a standalone
expression, doesn't mean '(a*a) + (b*b)'.
Google agrees with me (in that 2*2+3*3 shows 13), and so does my Casio
calculator.
It's not my personal opinion!
I'm sure you can trawl for some obscure languages where that expression
works differently, or where you can reassign priority or meaning to
those operators, but that is just being contrary for the sake of it.
> Reaching consensus
> on a question doesn't make the common view an objective one -- just
> a commonly held one.
So, the number of times in this group where I've been told that everyone
else disagrees with me about something so I must be wrong - this was
just your (pl) subjective opinion all along?
In the PL world then it is going to be mainly about subjective opinions!
There are few absolute truths.
But what about this example:
((((((a))))))
'Too many parentheses' is still subjective?
How about '((((a)))) using more parentheses than (a)'; that surely must
be objective?
> Here is a story from the earliest weeks of all of the time I have
> been programming. In one of the first few programs I ever wrote
> (and perhaps even the very first one), I had a statement like so:
>
> x = alpha/beta*gamma
>
> Of course the names here are made up, I don't remember the actual
> names used. When x was printed out, it gave a value that was
> much different from what I expected. What had happened was I had
> unconsciously assumed, reasoning by analogy with written
> mathematics, that the statement would be interpreted as
>
> alpha
> x = ------------
> beta*gamma
You will have quickly found out that PL syntax is not mathematics. For a
start, mathematics doesn't normally use '*', nor '/' for that matter.
Yes, there is a discrepancy with the precedences of divide and (implied)
multiply. However, a*a + b*b example didn't use divide.
(Note that C has its own problems in this area:
a = b/*p; // divide b by dereferenced pointer p
Here, /* also happens to start a block comment.)
> If someone really can't learn the rules of expression syntax for the
> language they are using, they should be advised to try a different
> language, or perhaps give up programming altogether.
It can be multiple languages, and they might want to write the same
expression the same way in each.
It could be no language: maybe its pseudo-code, or some unspecified
language in a forum which is not language-specific. They want anybody to
just understand it.
This is the scenerio I mentioned where you can risk not using
precedences when expressions involve "+ - * /", comparisons, and AND/OR
since generally these are treated sensibly by infix languages (even in
C, almost).
But operators such as '<< >> & ^ |' are treated more diversely. Here you
would be taking a bigger risk. You could label such code as 'C Syntax'
(if posting for example) but that is just being lazy.
> It's silly to
> worry about something that 999 people out of a 1000 (and the actual
> numbers are undoubtedly much higher) are able to navigate without
> difficulty. Yet the examples you give insist on focusing on the few
> hopeless individuals.
Are you saying that whoever wrote code like this:
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
is needlessly worrying about the 99.9+% of the readership who you claim
will know C syntax rules precisely? That is, they would find this
version just as clear without any extra cognitive effort:
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
?
If so then you are hopelessly wrong.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-04 14:35 +0200 |
| Message-ID | <10vrred$74ie$1@dont-email.me> |
| In reply to | #399678 |
On 04/06/2026 13:40, Bart wrote:
> On 04/06/2026 10:34, Tim Rentsch wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> My point was that it could be objective, at least for too many. So
>>> (a*a) + (b*b) would be commonly agreed to have too many, [...]
>>
>> Apparently you misunderstand what is meant by the word objective.
>> An objective statement is one that is independent of personal
>> assessment, even collective personal assessment.
>
> I don't know of any infix PL syntax where 'a*a + b*b', as a standalone
> expression, doesn't mean '(a*a) + (b*b)'.
>
> Google agrees with me (in that 2*2+3*3 shows 13), and so does my Casio
> calculator.
>
> It's not my personal opinion!
You are - again - moving the goalposts.
It is an objective fact that "a * a + b * b" means "(a * a) + (b * b)"
in normal mathematics (at least in the countries I am familiar with),
and also in most mainstream programming languages.
It is an objective fact, therefore, that "(a*a) + (b*b)" has more
parentheses than needed in the context of most programming languages.
"(a*a) + (b*b) has too many parentheses", on the other hand, is a purely
subjective opinion. Even if it is true that this is "commonly agreed
to" (and AFAIK you have no basis for that claim), that would still be a
subjective opinion - no matter how common that opinion is.
Does that clear up your misunderstanding about "objective" and
"subjective" ?
>
>> Reaching consensus
>> on a question doesn't make the common view an objective one -- just
>> a commonly held one.
>
> So, the number of times in this group where I've been told that everyone
> else disagrees with me about something so I must be wrong - this was
> just your (pl) subjective opinion all along?
Facts and opinions are different. You regularly get facts about C
wrong, and you are told you are wrong - that is objective. You
regularly give opinions that people disagree with, and are told they
disagree - that is subjective.
If you wrote, for example, that "a << b + c" is ambiguous in C, then you
would be factually and objectively wrong. If you wrote that it is
unclear, then you would be expressing a subjective opinion, and people
may or may not agree with you.
Sometimes you might voice an opinion that is so extreme or uncommon that
people might tell you you are wrong, when saying they disagree would be
more appropriate - discussions here are not formal.
>
> In the PL world then it is going to be mainly about subjective opinions!
> There are few absolute truths.
The programming language world is full of absolutely truths. The C
standards, for example, are full of facts about the C language. It is
not just a collection of guidelines or ideas for people to like or dislike.
>
> But what about this example:
>
> ((((((a))))))
>
> 'Too many parentheses' is still subjective?
Yes, obviously. "More parentheses than necessary" is objective, "too
many parentheses" is subjective. I expect most people will share the
same opinion, but it is still an opinion.
>
> How about '((((a)))) using more parentheses than (a)'; that surely must
> be objective?
Yes.
>
>> Here is a story from the earliest weeks of all of the time I have
>> been programming. In one of the first few programs I ever wrote
>> (and perhaps even the very first one), I had a statement like so:
>>
>> x = alpha/beta*gamma
>>
>> Of course the names here are made up, I don't remember the actual
>> names used. When x was printed out, it gave a value that was
>> much different from what I expected. What had happened was I had
>> unconsciously assumed, reasoning by analogy with written
>> mathematics, that the statement would be interpreted as
>>
>> alpha
>> x = ------------
>> beta*gamma
>
> You will have quickly found out that PL syntax is not mathematics. For a
> start, mathematics doesn't normally use '*', nor '/' for that matter.
It's not so much the symbols, as the layout. A mathematician would not
write "a÷b×c" either. They would write it in a way that makes the
intended precedence obvious to other mathematicians reading it, taking
into account the exact symbols used ("a.b" or "ab" might be considered
to bind tighter than "a×b"), the spacing, the position of the symbols on
the page, and - importantly - the context.
Programming can definitely be viewed as a sort of mathematics, but
writing code is not the same as writing mathematics.
>
> Yes, there is a discrepancy with the precedences of divide and (implied)
> multiply. However, a*a + b*b example didn't use divide.
>
> (Note that C has its own problems in this area:
>
> a = b/*p; // divide b by dereferenced pointer p
>
> Here, /* also happens to start a block comment.)
>
Here you are objectively wrong. C does not have a "problem" with this.
The parsing rules of the language are clear - often called "maximum
munch". The character sequence "/*" is the start of a comment, it is
not two separate operators.
You might personally have a problem with this. Whether you do or do not
is also an objective fact, but one that only you can judge. And you can
have a subjective opinion as to whether or not you like the rules of C here.
>
>
>> If someone really can't learn the rules of expression syntax for the
>> language they are using, they should be advised to try a different
>> language, or perhaps give up programming altogether.
>
> It can be multiple languages, and they might want to write the same
> expression the same way in each.
>
Sure.
I also don't think people should be required to learn all the details of
a language in order to use it. Indeed, for bigger languages (say, C++
or Python) it would be infeasible to learn everything. Exactly where
you draw the lines of what you need to know and what you can look up if
necessary will vary by person, and by the type of tasks they are doing
in a language.
> It could be no language: maybe its pseudo-code, or some unspecified
> language in a forum which is not language-specific. They want anybody to
> just understand it.
>
> This is the scenerio I mentioned where you can risk not using
> precedences when expressions involve "+ - * /", comparisons, and AND/OR
> since generally these are treated sensibly by infix languages (even in
> C, almost).
>
> But operators such as '<< >> & ^ |' are treated more diversely. Here you
> would be taking a bigger risk. You could label such code as 'C
> Syntax' (if posting for example) but that is just being lazy.
>
It is correct that details here vary more. Whether you think extra
parentheses should or should not be used is, however, a subjective
opinion. (My opinion is probably more in line with yours than Tim's
here - but it is still subjective.)
>> It's silly to
>> worry about something that 999 people out of a 1000 (and the actual
>> numbers are undoubtedly much higher) are able to navigate without
>> difficulty. Yet the examples you give insist on focusing on the few
>> hopeless individuals.
>
> Are you saying that whoever wrote code like this:
>
> crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
>
> is needlessly worrying about the 99.9+% of the readership who you claim
> will know C syntax rules precisely? That is, they would find this
> version just as clear without any extra cognitive effort:
>
> crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
>
> ?
Tim did not write that. That example was not on the list of examples
you gave recently. The examples a couple of posts up in this branch
were a lot simpler. (That does not mean that Tim's "999 out of 1000"
figures are based on evidence.)
>
> If so then you are hopelessly wrong.
>
>
[toc] | [prev] | [next] | [standalone]
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web