Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #396684 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2026-02-19 16:55 -0500 |
| Last post | 2026-03-16 09:04 +0100 |
| Articles | 20 on this page of 218 — 21 participants |
Back to article view | Back to comp.lang.c
Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-19 16:55 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-25 15:56 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-26 10:05 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-26 13:20 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 17:06 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 17:27 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-02-26 14:31 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-02-26 13:33 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 18:49 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 18:55 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 19:17 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 19:34 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-26 20:01 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 10:36 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 17:38 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 17:48 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-02-27 00:12 +0000
[OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 06:37 +0100
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Bart <bc@freeuk.com> - 2026-03-06 15:48 +0000
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 18:17 +0100
Re: [OT] Bart's scripting language solution (was Re: Sort of trivial code challenge - may be interesting to you anyway) Bart <bc@freeuk.com> - 2026-03-06 21:46 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 00:44 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-02 11:07 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 06:35 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-02 17:50 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 21:15 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-03 20:48 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-03 22:47 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-04 08:48 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 01:07 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 12:09 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 11:19 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-04 12:58 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:31 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-04 13:20 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 08:30 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-04 14:36 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 10:02 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 19:27 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 13:49 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-05 21:02 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-05 20:39 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 19:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 13:54 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:50 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-13 11:58 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-13 23:00 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:54 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-15 23:42 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 12:02 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:43 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-02 17:40 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-02 21:09 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-03 08:23 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 06:20 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-03 23:56 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 15:51 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-04 11:45 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 07:01 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:37 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 08:29 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-04 16:02 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 08:09 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 10:34 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:46 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 11:25 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 13:46 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-05 21:34 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 19:09 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 21:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 14:12 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-05 22:24 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 01:00 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 15:08 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 15:05 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-06 00:18 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-07 22:04 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:26 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-08 02:45 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:05 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:57 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 00:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 00:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 20:31 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-06 13:51 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:53 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 19:36 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 18:14 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 18:21 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-07 11:55 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 20:10 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 10:44 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-07 12:02 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-07 20:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 10:53 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 16:58 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-08 00:35 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 08:23 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:40 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-08 10:42 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-08 15:18 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-08 12:21 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-08 19:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-09 21:20 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-10 14:43 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-10 18:08 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Giovanni <lsodgf0@home.net.it> - 2026-03-10 17:18 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-10 16:32 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-10 15:25 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:07 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-11 13:49 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-10 20:24 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-10 15:29 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-11 00:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-11 00:33 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-11 11:04 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway antispam@fricas.org (Waldek Hebisch) - 2026-03-10 20:18 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:37 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:57 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-08 13:19 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-09 01:12 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-08 21:42 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-08 15:58 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-09 08:09 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-09 08:53 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-09 15:25 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 14:40 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-12 05:55 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-08 16:00 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 12:44 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 17:36 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-08 13:27 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 06:33 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway David Brown <david.brown@hesbynett.no> - 2026-03-08 12:22 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 06:27 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-07 16:43 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-11 07:29 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-11 14:22 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 10:07 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:54 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 03:13 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-06 16:02 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 12:11 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 13:01 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 13:28 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-06 21:53 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-06 22:14 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-07 07:33 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 10:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-07 19:16 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 14:18 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-08 00:47 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-09 22:18 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-10 10:14 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-11 11:40 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-07 13:33 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-07 14:53 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bart <bc@freeuk.com> - 2026-03-07 15:44 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-07 19:53 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-07 10:22 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:40 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-11 11:00 -0400
Re: Sort of trivial code challenge - may be interesting to you anyway wij <wyniijj5@gmail.com> - 2026-03-12 00:00 +0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 18:03 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-11 17:52 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway wij <wyniijj5@gmail.com> - 2026-03-12 23:14 +0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:23 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-12 16:11 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 14:04 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:36 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-11 11:35 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-03 15:40 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 16:23 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-03-04 15:31 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-04 09:38 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-03 16:39 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-03 12:00 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-04 11:44 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 17:44 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-04 15:13 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-04 21:07 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-04 23:37 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 07:32 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 08:23 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 02:24 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 08:46 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 09:52 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway tTh <tth@none.invalid> - 2026-03-05 10:49 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 11:03 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway gazelle@shell.xmission.com (Kenny McCormack) - 2026-03-05 15:22 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 05:06 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 11:13 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway DFS <nospam@dfs.com> - 2026-03-05 14:11 -0500
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 03:35 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-05 14:49 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-05 19:27 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-05 19:46 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway tTh <tth@none.invalid> - 2026-03-05 20:50 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-05 22:34 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 07:48 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 11:49 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 13:41 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 15:33 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-06 14:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 13:49 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-06 02:17 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-05 20:06 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-06 14:58 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Michael S <already5chosen@yahoo.com> - 2026-03-06 17:13 +0200
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 08:37 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway scott@slp53.sl.home (Scott Lurndal) - 2026-03-03 17:29 +0000
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-03 19:20 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-03 16:26 -0800
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-04 05:27 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Opus <ifonly@youknew.org> - 2026-03-04 22:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway peter <peter.noreply@tin.it> - 2026-03-14 10:42 +0100
Re: Sort of trivial code challenge - may be interesting to you anyway Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 15:09 -0700
Re: Sort of trivial code challenge - may be interesting to you anyway Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-16 09:04 +0100
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-09 01:12 +0000 |
| Message-ID | <10ol6p1$2squv$1@dont-email.me> |
| In reply to | #396872 |
On 08/03/2026 20:19, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> Funny though how TR castigated me for not offering a C solution, but >> his solution is one I would not class as C code, as it only uses a >> subset of the language and in a weird manner (a bit like some of my >> generated C which is not meant to be human-readable). > [...] > > Nonsense. Of course Tim's code was C code. It compiles without > error with a conforming C compiler, and does not depend on any > extensions. Practically all C programs only use a subset of the > language. See my followup to DFS's reply to my post. > Classifying C code that you don't like as "not C" is absurd. That it compiles is a low bar. You should see some of the 'flat' C code I generate from a linear IL, where there is no code structure, and no proper data structures (everything is a struct containing only a byte-array.) It is only technically C, yet it also 'compiles'. Normally that kind of program is machine-generated, but some like to write it manually (IOCCC for example). > Your code, on the other hand, was not written in C at all. If plotted on a chart which quantifies easy of understanding, that it will be next to the C version that I also posted, which TR's version will be quite a way off. Of course, mine doesn't have the same restrictions, and a slightly different spec. If I had some time (and could figure out how it worked), I could duplicate the approach in another language, with the same limitations, and it would probably be much clearer, because that's what I do. (For that matter, even the C as posted could be improved.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-08 21:42 +0000 |
| Message-ID | <g3mrR.1321$Ah%d.448@fx11.iad> |
| In reply to | #396865 |
Bart <bc@freeuk.com> writes:
>On 08/03/2026 14:42, DFS wrote:
>> On 3/7/2026 6:40 PM, Janis Papanagnou wrote:
>>> On 07.03.26 22:58, DFS wrote:
>>>> On 3/7/2026 3:02 PM, Tim Rentsch wrote:
>>>>> [...]
>>>>
>>>> What do you think would be the reaction in a corporate programming
>>>> dept to this unique kind of code?
>>>
>>> From my experiences in a couple such departments of professional
>>> software development...
>>>
>>> The "uniqueness" would not be a problem. It would have failed to
>>> many requirements that maintainable code was expected to have.
>>
>> I figured as much.
>>
>>
>> Nested ternaries like this:
>>
>> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3;
>>
>> are harder to decipher at first glance than 3 or 4 levels of indented
>> if-then-elses.
>
>TR doesn't like parentheses around ?: terms; everyone is expected to
>know their precedence.
Most coding standards, IIRC, specify that explicit groupings
should be used, so any future code reader would know what
the programmer intended.
Google AI agrees:
Safety and Intent: Parentheses explicitly define the intended order of operations,
ensuring the code behaves as expected regardless of the specific
language's precedence rules.
Readability and Maintenance: Code is written for humans to read. Extra parenthess
make complex expressions easier to understand, reducing the "cognitive load" needed
to calculate the precedence mentally.
Preventing Errors: Using parentheses prevents bugs when expressions are modified
later by other developers who may not be fully aware of the default order of operations.
Compiler/Standard Limitations: Some, albeit rare, languages or strict
standards (like MISRA C:2023 or the Pony language) require explicit
parentheses to eliminate ambiguity entirely.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-03-08 15:58 -0700 |
| Message-ID | <10okuvh$2qkoa$1@dont-email.me> |
| In reply to | #396874 |
On 3/8/2026 2:42 PM, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 08/03/2026 14:42, DFS wrote: >>> On 3/7/2026 6:40 PM, Janis Papanagnou wrote: >>>> On 07.03.26 22:58, DFS wrote: >>>>> On 3/7/2026 3:02 PM, Tim Rentsch wrote: >>>>>> [...] >>>>> >>>>> What do you think would be the reaction in a corporate programming >>>>> dept to this unique kind of code? >>>> >>>> From my experiences in a couple such departments of professional >>>> software development... >>>> >>>> The "uniqueness" would not be a problem. It would have failed to >>>> many requirements that maintainable code was expected to have. >>> >>> I figured as much. >>> >>> >>> Nested ternaries like this: >>> >>> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3; >>> >>> are harder to decipher at first glance than 3 or 4 levels of indented >>> if-then-elses. >> >> TR doesn't like parentheses around ?: terms; everyone is expected to >> know their precedence. > > Most coding standards, IIRC, specify that explicit groupings > should be used, so any future code reader would know what > the programmer intended. > > Google AI agrees: > > Safety and Intent: Parentheses explicitly define the intended order of operations, > ensuring the code behaves as expected regardless of the specific > language's precedence rules. > > Readability and Maintenance: Code is written for humans to read. Extra parenthess > make complex expressions easier to understand, reducing the "cognitive load" needed > to calculate the precedence mentally. > > Preventing Errors: Using parentheses prevents bugs when expressions are modified > later by other developers who may not be fully aware of the default order of operations. > > Compiler/Standard Limitations: Some, albeit rare, languages or strict > standards (like MISRA C:2023 or the Pony language) require explicit > parentheses to eliminate ambiguity entirely. > (x * y) + z Well, its, ivho its "better" to have the parenthesis in there...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-09 08:09 +0100 |
| Message-ID | <10olrnl$32iuh$1@dont-email.me> |
| In reply to | #396875 |
On 08/03/2026 23:58, Chris M. Thomasson wrote: > On 3/8/2026 2:42 PM, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 08/03/2026 14:42, DFS wrote: >>>> On 3/7/2026 6:40 PM, Janis Papanagnou wrote: >>>>> On 07.03.26 22:58, DFS wrote: >>>>>> On 3/7/2026 3:02 PM, Tim Rentsch wrote: >>>>>>> [...] >>>>>> >>>>>> What do you think would be the reaction in a corporate programming >>>>>> dept to this unique kind of code? >>>>> >>>>> From my experiences in a couple such departments of professional >>>>> software development... >>>>> >>>>> The "uniqueness" would not be a problem. It would have failed to >>>>> many requirements that maintainable code was expected to have. >>>> >>>> I figured as much. >>>> >>>> >>>> Nested ternaries like this: >>>> >>>> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3; >>>> >>>> are harder to decipher at first glance than 3 or 4 levels of indented >>>> if-then-elses. >>> >>> TR doesn't like parentheses around ?: terms; everyone is expected to >>> know their precedence. >> >> Most coding standards, IIRC, specify that explicit groupings >> should be used, so any future code reader would know what >> the programmer intended. >> >> Google AI agrees: >> >> Safety and Intent: Parentheses explicitly define the intended >> order of operations, >> ensuring the code behaves as expected >> regardless of the specific >> language's precedence rules. >> >> Readability and Maintenance: Code is written for humans to read. >> Extra parenthess >> make complex expressions easier to understand, reducing the >> "cognitive load" needed >> to calculate the precedence mentally. >> >> Preventing Errors: Using parentheses prevents bugs when >> expressions are modified >> later by other developers who may not be fully aware of the >> default order of operations. >> >> Compiler/Standard Limitations: Some, albeit rare, languages or strict >> standards (like MISRA C:2023 or the Pony language) require explicit >> parentheses to eliminate ambiguity entirely. >> > > (x * y) + z > > Well, its, ivho its "better" to have the parenthesis in there... You need to find the right balance when deciding when parentheses are appropriate. The precedence of multiply and addition is well established from arithmetic in early school days, so "x * y + z" is clear. The tertiary operator is only known from C and a few other programming languages, thus its precedence is not clear until the programmer is familiar with it. And since it is not nearly as widely used as multiplication and addition, especially in complex expressions, even many experienced C programmers can sometimes get it wrong. Where you put the requirements in a coding standard can depend on many factors. Are you aiming for code that is easily understood even by relatively new C programmers, or do you expect only experts to be dealing with the code? Are you writing code that can be used with a wide variety of compilers (some of which may be buggy, or generate poor quality code, especially in complex situations) ? What are the consequences of misunderstandings of the code? (You have different rules for aircraft engine control systems and a computer game.) All sorts of things affect readability, and operator precedence and parentheses is only one of them. (Of course the code in this thread is not written for readability.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou@hotmail.com> |
|---|---|
| Date | 2026-03-09 08:53 +0100 |
| Message-ID | <10olu9d$32s86$1@dont-email.me> |
| In reply to | #396877 |
On 09.03.26 08:09, David Brown wrote: > > Where you put the requirements in a coding standard can depend on many > factors. Are you aiming for code that is easily understood even by > relatively new C programmers, or do you expect only experts to be > dealing with the code? [...] Just a comment on this point. - In commercial companies the code is the (sort of) invariant, the people (the programmers) change. So generally you can't make such assumptions about the staff. You want provisions for the code quality by rules to obtain sufficient maintainability. Or else you need a sophisticated risk management. (Or replace programmers by AI in the first place. - *shudder* - I am joking, others might not.) Even when having employed only "experts" - in whatever way you would qualify that - (and their availability also somehow guaranteed), the code should be easily readable, not cryptic or convoluted. IME even the "experts" amongst the programmers are grateful for maintainable code, and the management as well, saving time, money, and keeping reputation high by preventing or reducing issues from bad code quality effects. Janis
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-03-09 15:25 -0700 |
| Message-ID | <10onhci$3p1dn$1@dont-email.me> |
| In reply to | #396877 |
On 3/9/2026 12:09 AM, David Brown wrote: > On 08/03/2026 23:58, Chris M. Thomasson wrote: >> On 3/8/2026 2:42 PM, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 08/03/2026 14:42, DFS wrote: >>>>> On 3/7/2026 6:40 PM, Janis Papanagnou wrote: >>>>>> On 07.03.26 22:58, DFS wrote: >>>>>>> On 3/7/2026 3:02 PM, Tim Rentsch wrote: >>>>>>>> [...] >>>>>>> >>>>>>> What do you think would be the reaction in a corporate programming >>>>>>> dept to this unique kind of code? >>>>>> >>>>>> From my experiences in a couple such departments of professional >>>>>> software development... >>>>>> >>>>>> The "uniqueness" would not be a problem. It would have failed to >>>>>> many requirements that maintainable code was expected to have. >>>>> >>>>> I figured as much. >>>>> >>>>> >>>>> Nested ternaries like this: >>>>> >>>>> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3; >>>>> >>>>> are harder to decipher at first glance than 3 or 4 levels of indented >>>>> if-then-elses. >>>> >>>> TR doesn't like parentheses around ?: terms; everyone is expected to >>>> know their precedence. >>> >>> Most coding standards, IIRC, specify that explicit groupings >>> should be used, so any future code reader would know what >>> the programmer intended. >>> >>> Google AI agrees: >>> >>> Safety and Intent: Parentheses explicitly define the intended >>> order of operations, >>> ensuring the code behaves as expected >>> regardless of the specific >>> language's precedence rules. >>> >>> Readability and Maintenance: Code is written for humans to read. >>> Extra parenthess >>> make complex expressions easier to understand, reducing the >>> "cognitive load" needed >>> to calculate the precedence mentally. >>> >>> Preventing Errors: Using parentheses prevents bugs when >>> expressions are modified >>> later by other developers who may not be fully aware of the >>> default order of operations. >>> >>> Compiler/Standard Limitations: Some, albeit rare, languages or >>> strict >>> standards (like MISRA C:2023 or the Pony language) require >>> explicit >>> parentheses to eliminate ambiguity entirely. >>> >> >> (x * y) + z >> >> Well, its, ivho its "better" to have the parenthesis in there... > > You need to find the right balance when deciding when parentheses are > appropriate. Well, agreed for sure. x * y + z is, or should be easy to any "qualified" person to know about the precedence. But, I have seen some errors long time ago with somebody going: x * y + addend * z Well, they really wanted: (x * y + addend) * z ((x * y) + addend) * z ;^) So, it depends in a sense. > The precedence of multiply and addition is well > established from arithmetic in early school days, so "x * y + z" is > clear. The tertiary operator is only known from C and a few other > programming languages, thus its precedence is not clear until the > programmer is familiar with it. And since it is not nearly as widely > used as multiplication and addition, especially in complex expressions, > even many experienced C programmers can sometimes get it wrong. I tend to shy away from the ? operator. If I do use it I make sure to add parentheses on all sides. ((condition) ? (true) : (false)) > > Where you put the requirements in a coding standard can depend on many > factors. Are you aiming for code that is easily understood even by > relatively new C programmers, or do you expect only experts to be > dealing with the code? Say that expectation of "expert" can be "relative", what is an expert? Say expert in certain areas, not so much in others? > Are you writing code that can be used with a > wide variety of compilers (some of which may be buggy, or generate poor > quality code, especially in complex situations) ? What are the > consequences of misunderstandings of the code? (You have different > rules for aircraft engine control systems and a computer game.) Well, a little bug in a game can give it some spice, in a strange sense. A bug in an steering system, well it will make you taste kung pao scallops as you drive right off the road... > > All sorts of things affect readability, and operator precedence and > parentheses is only one of them. > > (Of course the code in this thread is not written for readability.) >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-11 14:40 -0700 |
| Message-ID | <86eclq82pu.fsf@linuxsc.com> |
| In reply to | #396874 |
scott@slp53.sl.home (Scott Lurndal) writes: > Bart <bc@freeuk.com> writes: > >> On 08/03/2026 14:42, DFS wrote: >> >>> On 3/7/2026 6:40 PM, Janis Papanagnou wrote: >>> >>>> On 07.03.26 22:58, DFS wrote: >>>> >>>>> On 3/7/2026 3:02 PM, Tim Rentsch wrote: >>>>> >>>>>> [...] >>>>> >>>>> What do you think would be the reaction in a corporate programming >>>>> dept to this unique kind of code? >>>> >>>> From my experiences in a couple such departments of professional >>>> software development... >>>> >>>> The "uniqueness" would not be a problem. It would have failed to >>>> many requirements that maintainable code was expected to have. >>> >>> I figured as much. >>> >>> >>> Nested ternaries like this: >>> >>> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3; >>> >>> are harder to decipher at first glance than 3 or 4 levels of indented >>> if-then-elses. >> >> TR doesn't like parentheses around ?: terms; everyone is expected to >> know their precedence. > > Most coding standards, IIRC, specify that explicit groupings > should be used, so any future code reader would know what > the programmer intended. Some miscellaneous thoughts on programming style: Most "coding standards" are style guidelines, not coding standards. Aesthetic debates are never just about aesthetics. Large-scale structure is more important than small-scale details. "Readable" means different things to different people. Most of the comments about readability are like what the Supreme Court said about pornography: they can't define it, but they know it when they see it. Remember the advice of Dijkstra: don't make the mistake of thinking something is convenient just because it is conventional.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-12 05:55 -0700 |
| Message-ID | <861php8awe.fsf@linuxsc.com> |
| In reply to | #396865 |
Bart <bc@freeuk.com> writes: [...] > Funny though how TR castigated me for not offering a C solution, No, I didn't. I said only that I see no reason to answer your questions since you seem to have no interest in writing C code. > but his solution is one I would not class as C code, Your sense of self-importance is truly remarkable.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-03-08 16:00 +0000 |
| Message-ID | <10ok6f2$2ejoa$1@dont-email.me> |
| In reply to | #396864 |
On Sun, 08 Mar 2026 10:42:34 -0400, DFS wrote: [snip] > Sure it's a bearded-lady novelty, but I think he knocked it out of the park. I think of it as an educational opportunity. Look at how succinctly Tim's code satisfied not only your requirements, but the outrageously restrictive constraints his counter-challenge posed. With his solution, he implemented an 84 line finite state machine that matched your 131 line example. I, for one, will spend a fair bit of time studying /how/ his code works, and gleaning some techniques to improve /my/ coding. Just my $0.02 worth. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-11 12:44 -0700 |
| Message-ID | <86ikb28823.fsf@linuxsc.com> |
| In reply to | #396866 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > On Sun, 08 Mar 2026 10:42:34 -0400, DFS wrote: > [snip] > >> Sure it's a bearded-lady novelty, but I think he knocked it out of >> the park. > > I think of it as an educational opportunity. Look at how succinctly > Tim's code satisfied not only your requirements, but the outrageously > restrictive constraints his counter-challenge posed. > > With his solution, he implemented an 84 line finite state machine > that matched your 131 line example. I, for one, will spend a fair > bit of time studying /how/ his code works, and gleaning some > techniques to improve /my/ coding. > > > Just my $0.02 worth. My purpose in posing the counter challenge was two fold: one, to offer an opportunity for an educational exercise; and two, to illustrate a high-level structural pattern that might not be familiar to people. Also I had fun writing my program, and it was a pleasure to post it. There are some aspects to my posted code that are just byproducts of some general principles I follow in code writing rather than meant to illustrate anything in particular. I like code that looks clean. I generally favor holding state in variables rather than using control flow. I like code to be succinct, which tends to mean fewer lines, but there is a tension between number of lines and line width; for C code I self-impose an upper limit of 79 columns, and try to avoid wrapping lines. I try to write code that is understandable and self-explanatory, but that is a more subjective area, and of course there are tradeoffs with other properties desired. Scale is important: being comprehensible on a large scale is given as much weight as what is done on a small scale. People who focus on small scale appearance, especially in the posted example code, are in danger of missing the point. Hopefully my commentary in the preceding paragraph will help you in getting more value out of my little example program.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou@hotmail.com> |
|---|---|
| Date | 2026-03-08 17:36 +0100 |
| Message-ID | <10ok8ig$2fnjg$2@dont-email.me> |
| In reply to | #396864 |
On 08.03.26 15:42, DFS wrote: > On 3/7/2026 6:40 PM, Janis Papanagnou wrote: >> On 07.03.26 22:58, DFS wrote: >>> On 3/7/2026 3:02 PM, Tim Rentsch wrote: >>>> [...] >>> >>> What do you think would be the reaction in a corporate programming >>> dept to this unique kind of code? >> [...] >> The "uniqueness" would not be a problem. It would have failed to >> many requirements that maintainable code was expected to have. > > I figured as much. I assumed so but wanted to be on the safe side. > > Nested ternaries like this: > > c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3; > > are harder to decipher at first glance than 3 or 4 levels of indented > if-then-elses. Personally I've no reservations concerning the ternary conditional. I think it depends on the actual code complexity and code context what to be best used. And using the conditional ternary is also not the primary problem with that code. (The unreadability here stems from a couple other factors, the ternary at best supports these factors.) > > But all the decision-making in one short line is a thing of beauty. Well, personally I like, for example, the Obfuscated "C" Contest. And generally, in other contexts, also clever one-liner solutions. (The code here reminds me of some of my BASIC code that I wrote in the 1970's, though.) Whether it's sensible to apply this in an algorithmic challenge is obviously a matter of taste (as it seems). > >> I can explain the (positive) excitement only by some nerdy stance >> in this specific CLC domain. > > Give the man his due. It's extremely unique and excitement-worthy. On a CLC nerd level, yes. (My own excitement went in the other direction, though; hoping that this code will not become a paragon for software developers.) > > What's also very nice is there are no long lines that wrap. That's not a quality measure if it's gained by unreadable content. Janis > > Sure it's a bearded-lady novelty, but I think he knocked it out of the > park. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-08 13:27 -0700 |
| Message-ID | <87zf4ixe1g.fsf@example.invalid> |
| In reply to | #396864 |
DFS <nospam@dfs.com> writes:
[...]
> Nested ternaries like this:
>
> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3;
>
> are harder to decipher at first glance than 3 or 4 levels of indented
> if-then-elses.
A nested ternary can be readable if you format it carefully,
particularly if implements something similar to a linear if/else chain.
I might write the above at:
c = square ? a1 :
!hwc ? h*w :
a3 > h*w ? h*w :
a3;
or even:
c = square ? a1 :
!hwc ? h*w :
a3 > h*w ? h*w :
a3;
(The second and third conditions could be combined with "||".)
It could be rewritten as an if/else chain like this:
if (square) c = a1;
else if (!hwc) c = h*w;
else if (a3 > h*w) c = h*w;
else c = a3;
> But all the decision-making in one short line is a thing of beauty.
For certain values of "beauty".
[...]
--
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-03-11 06:33 -0700 |
| Message-ID | <86cy1aa3sr.fsf@linuxsc.com> |
| In reply to | #396864 |
DFS <nospam@dfs.com> writes:
[...]
> Nested ternaries like this:
>
> c = square ? a1 : !hwc ? h*w : a3 > h*w ? h*w : a3;
>
> are harder to decipher at first glance than 3 or 4 levels of
> indented if-then-elses.
Again that is only because you aren't used to them. Note by the
way that the conditional expression is not nested, any more than
a chain of if-elseif-elseif-else is nested
if(x){
...
} else if(y){
...
} else if(z){
...
} else {
...
}
Of course syntactically this construct is nested, but normally
how people think of it is not as being nested.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-08 12:22 +0100 |
| Message-ID | <10ojm5a$2a5vq$1@dont-email.me> |
| In reply to | #396855 |
On 07/03/2026 22:58, DFS wrote: > On 3/7/2026 3:02 PM, Tim Rentsch wrote: >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >> >>> [...] I look forward to seeing /your/ code :-) >> >> Here we go... > > > OMG! Congrats on an innovative piece of C code. Never seen anything > like it. > > I don't understand everything yet, but nested ternaries aside, it's > pretty easy to follow too. > > A nit you may have forgotten: you earlier said main() was not allowed: > > "not mentioning main() was an oversight on my part. > (Still not okay to call it.)" > > I saw David Brown offered about 5 ways to bypass main(). > > Note that none of the methods I suggested are portable - and I believe the challenge required portable C. The challenge did allow you to have a main() function (indeed, I think it is implicitly required) - it just disallowed /calling/ main() from your code. If you can think of a portable way to have a C program linked and running code without a main(), I would be curious to hear it. (I did once have a real program for a real product, where the code was written in C but did not have a "main". This was a /very/ small microcontroller, and the compiler automatically added extra code at the start of "main" that I wanted to avoid. So I had my own C runtime startup code from device reset, jumping to my C "real_main()" function without ever having a "main()" function.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-11 06:27 -0700 |
| Message-ID | <86h5qma43t.fsf@linuxsc.com> |
| In reply to | #396855 |
DFS <nospam@dfs.com> writes: [some of posting being responded to has been taken out without further notice]. > On 3/7/2026 3:02 PM, Tim Rentsch wrote: > >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >> >>> [...] I look forward to seeing /your/ code :-) >> >> Here we go... > > OMG! Congrats on an innovative piece of C code. Never seen > anything like it. Thank you, that's always nice to hear. > I don't understand everything yet, but nested ternaries aside, it's > pretty easy to follow too. Once you get used to them I think you'll find conditional expressions are easier to follow than if() chains. > A nit you may have forgotten: you earlier said main() was not > allowed: No, I didn't. You asked "Is main() OK?". I replied "Yes" followed by a short elaboration. Having main() be present is okay; calling it is not. The oversight was not mentioning that main is allowed. > Also I have a 'challenge' to add to your program - that I already > added to mine - to make it even more compelling: > > * when looking for a square matrix, instead of printing 'no joy' > print out a matrix that will visually demonstrate why the number > doesn't fit in a square matrix. > > For instance: > > ./rc-dfs 17 > square matrix for 1-17 not possible > -------------------- > 1 2 3 4 5 > -------------------- > 1 6 11 16 > 2 7 12 17 > 3 8 13 > 4 9 14 > 5 10 15 > > If you get stuck, I'll give you a hint :) A straightforward exercise. A challenge for you is to start with my program and adapt it, writing in the same style, to add this functionality. Now that you have seen my example code I think you should be able to adapt it without too much difficulty. > What do you think would be the reaction in a corporate programming > dept to this unique kind of code? What characteristics or properties would you say are the salient ones for the question you're asking?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-07 16:43 -0800 |
| Message-ID | <878qc3ywuk.fsf@example.invalid> |
| In reply to | #396851 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> typedef size_t Z;
> typedef _Bool B;
[...]
Why do you do this? I find that it makes the code more difficult to
read.
--
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-03-11 07:29 -0700 |
| Message-ID | <864imma17o.fsf@linuxsc.com> |
| In reply to | #396860 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >> typedef size_t Z; >> typedef _Bool B; > > [...] > > Why do you do this? I find that it makes the code more difficult > to read. The reaction from Lew Pitcher was "Brilliant!". The reaction from DFS was "I think he knocked it out of the park." Because Lew and DFS (and to some extent Michael S) are the ones who had expressed an interest in my counter challenge, they were my target audience. So from my point of view there is no reason to be dissatisfied with what was posted.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-11 14:22 -0700 |
| Message-ID | <87v7f212pp.fsf@example.invalid> |
| In reply to | #396903 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> typedef size_t Z;
>>> typedef _Bool B;
>>
>> [...]
>>
>> Why do you do this? I find that it makes the code more difficult
>> to read.
>
> The reaction from Lew Pitcher was "Brilliant!". The reaction from
> DFS was "I think he knocked it out of the park." Because Lew and
> DFS (and to some extent Michael S) are the ones who had expressed
> an interest in my counter challenge, they were my target audience.
> So from my point of view there is no reason to be dissatisfied with
> what was posted.
You are of course not obligated to answer, but surely it would be easier
not to post a followup at all.
--
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-04-25 10:07 -0700 |
| Message-ID | <861pg33r4w.fsf@linuxsc.com> |
| In reply to | #396914 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> [...] >>> >>>> typedef size_t Z; >>>> typedef _Bool B; >>> >>> [...] >>> >>> Why do you do this? I find that it makes the code more difficult >>> to read. >> >> The reaction from Lew Pitcher was "Brilliant!". The reaction from >> DFS was "I think he knocked it out of the park." Because Lew and >> DFS (and to some extent Michael S) are the ones who had expressed >> an interest in my counter challenge, they were my target audience. >> So from my point of view there is no reason to be dissatisfied with >> what was posted. > > You are of course not obligated to answer, but surely it would be easier > not to post a followup at all. I'm baffled by your comment. You asked a question. I didn't have any reason to think the question was rhetorical. I had something to say in response. I posted it. As to the last point, surely it would have been easier if you had not posted your comments either. And yet you did.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 15:54 -0700 |
| Message-ID | <10sjgmf$1668o$6@kst.eternal-september.org> |
| In reply to | #397940 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>
>>>>> typedef size_t Z;
>>>>> typedef _Bool B;
>>>>
>>>> [...]
>>>>
>>>> Why do you do this? I find that it makes the code more difficult
>>>> to read.
>>>
>>> The reaction from Lew Pitcher was "Brilliant!". The reaction from
>>> DFS was "I think he knocked it out of the park." Because Lew and
>>> DFS (and to some extent Michael S) are the ones who had expressed
>>> an interest in my counter challenge, they were my target audience.
>>> So from my point of view there is no reason to be dissatisfied with
>>> what was posted.
>>
>> You are of course not obligated to answer, but surely it would be easier
>> not to post a followup at all.
>
> I'm baffled by your comment. You asked a question. I didn't
> have any reason to think the question was rhetorical. I had
> something to say in response. I posted it. As to the last
> point, surely it would have been easier if you had not posted
> your comments either. And yet you did.
You responded, but you didn't answer. I still don't know why you
wrote those typedefs, nor do I know why you chose not to answer
my direct question.
I'm still slightly curious why you would use (IMHO) silly names
like Z and B (that was the specific questio I asked), but I'm no
longer asking you to explain.
I'll try to cut back on asking you why you write things.
--
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]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web