Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #402647 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-03 08:43 +0000 |
| Last post | 2026-10-13 23:19 +0100 |
| Articles | 20 on this page of 423 — 22 participants |
Back to article view | Back to comp.lang.c
Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
[OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 13:12 -0700
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 04:46 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 14:22 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:00 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 01:29 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:48 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 12:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:09 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:34 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:13 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:52 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:16 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 20:47 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 22:38 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 11:16 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 03:50 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:59 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:28 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:05 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 14:35 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 18:31 +0200
Re: Taming The Switch-Statement Bob Duff <invalid@invalid.com> - 2026-10-19 19:38 -0400
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 17:03 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:45 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 05:01 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 00:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:34 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 17:49 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:18 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-18 23:51 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-19 01:56 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 19:37 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 23:56 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:15 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-18 18:33 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 13:39 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-19 08:47 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 18:28 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 16:11 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 01:02 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 09:18 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-18 22:33 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-20 02:53 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 12:22 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 19:39 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 18:23 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:36 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-17 21:03 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 10:30 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-17 10:54 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-19 23:41 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:18 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:02 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 21:09 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-12 22:31 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:32 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 23:14 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-13 07:23 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:26 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-13 12:10 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 06:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 13:33 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 13:41 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 14:38 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 18:04 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 20:52 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 22:24 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 00:03 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:53 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-14 17:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:48 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:16 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 21:54 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-16 15:24 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-16 21:42 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-16 21:46 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 12:38 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 15:03 -0700
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 19:25 -0700
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 00:16 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 07:40 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 16:46 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 09:10 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 18:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:27 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-14 01:50 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 10:58 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 22:54 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-13 16:45 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:34 -0700
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-14 05:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 13:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 19:05 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:15 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:43 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:45 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 23:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:56 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 20:38 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:52 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-12 22:56 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 21:57 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 21:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 22:46 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-13 09:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 12:18 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 11:33 +0100
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 00:25 +0300
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:20 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:02 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 01:53 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 03:54 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-13 10:52 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-13 23:16 +0300
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 18:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 17:33 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 00:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 20:40 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 03:59 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-13 21:35 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 11:27 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 12:17 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 12:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 16:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:30 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-14 23:28 +0300
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 21:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:56 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 21:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 01:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 12:01 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 11:45 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 15:57 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 18:10 +0100
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-16 02:42 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:42 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-15 23:57 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 23:22 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-16 12:40 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 00:01 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-16 16:53 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-17 11:09 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 13:11 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-17 15:15 +0200
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-17 08:34 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 03:19 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 12:34 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 17:58 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-17 21:40 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 14:32 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 01:19 +0000
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 09:18 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 12:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 12:47 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 14:08 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-19 17:22 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 20:34 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:35 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 00:04 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-20 01:03 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 15:11 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:02 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 13:22 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 14:12 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 14:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:27 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 17:09 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:09 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 23:20 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 12:26 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:16 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-19 15:46 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 16:03 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 22:28 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:01 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 12:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 14:58 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-19 15:48 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 01:18 +0200
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-19 08:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-19 15:00 +0100
Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-19 16:55 +0100
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-20 02:40 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 17:24 +0300
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 16:58 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 18:26 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-18 18:11 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-18 19:32 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 15:44 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-19 22:35 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-19 23:29 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 00:57 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 00:55 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 10:25 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-20 16:56 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-20 17:32 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-18 21:11 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-18 18:34 +0100
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-15 05:17 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 14:37 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 20:50 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-15 19:59 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-15 20:49 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-14 18:51 +0100
Re: Taming The Switch-Statement "Peyton" <peyton@solacium.com> - 2026-10-14 11:04 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-14 19:47 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 13:58 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-15 12:08 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-14 14:23 -0700
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-14 14:35 +0000
Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-16 03:36 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-12 17:02 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 20:04 +0800
Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-13 17:28 +0000
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-14 02:05 +0800
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 17:17 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:37 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 17:34 +0000
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 18:46 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 19:52 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:42 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:29 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 00:53 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 18:14 -0700
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 22:35 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-12 16:14 -0700
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-13 22:00 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-13 23:19 +0100
Page 18 of 22 — ← Prev page 1 … 16 17 [18] 19 20 … 22 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-20 01:18 +0200 |
| Message-ID | <11b68gm$1kr9u$9@dont-email.me> |
| In reply to | #403344 |
On 2026-10-20 00:48, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-10-18 21:09, David Brown wrote: >>> On 18/10/2026 18:09, bart wrote: >>>> [...] >> [ declaration syntax ] >> >> (I just want to comment on a [not unimportant] detail...) >> >>> You need to give things in the right order, or use parentheses, to >>> get the right "type expression". It's just like any other kind of >>> expression. >>> The intention of the declaration syntax in C is that the declaration >>> order follows usage. [...] >> >> I think the first part is downplaying that languages typically indeed >> make a distinction between parenthesized expressions and declarations. >> Quite some other languages [not from the C-heritage] that I used all >> did not need to introduce "expression"-grouping for _declarations_ in >> the first place given their more consistent ways to declare entities. > > Just one quibble. C's declaration syntax *is* consistent. Its > rules are rigorously specified by the standard, particularly by > the grammar. Yes, sure. It's well defined and all that. - What I tried to express by that is that the building rules are not... - coherent, consistent? Well, I think on that level speaking about "inconsistency" is fine. But okay. I think we all know what we have with C's declaration syntax. (And we all, but maybe one, can live with it.) > > Many of us (myself included) don't particularly like it, but that > doesn't mean it's inconsistent. > > My own take on all this is that having declaration syntax follow usage > was a very clever idea, where "clever" is not necessarily a compliment. Well, to return the quibble, clever is a compliment (while "clever" in quotes is obviously not). :-) I don't consider it to have been a clever idea. (No quotes.) But I had mentioned that elsethread already before, and it's IMO not worth a dispute. > It was IMHO unsuccessful in the sense that it can lead to confusing > and overly complicated declarations. And that's the essence of the criticism, I think. > (Other languages don't have tools > corresponding to cdecl for much the same reason that Spanish-speaking > countries don't have spelling bees.) But it was extraordinarily > successful in the sense that, even if you think it was a bad idea, > it wasn't bad enough to keep C from becoming one of the most popular > programming languages. Undoubtedly. (It wasn't bad enough.) - Now imagine if it were better! Would have all folks using - what-do-I-know, say, Java - then have settled with "C"? - I'm just kidding. > > (I wonder if keeping the declaration-follows-use principle while > making "*" a postfix operator might have improved things.) I'm confused about the recent emphasis of such a change; it very much sounds to me like: "we have a problem lets try fixing it by changing something else [instead of addressing the problem]"; both are useless thoughts. (Yes, I understand that you think about it academically.) Janis
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-19 08:46 +0000 |
| Message-ID | <11b4le0$4fik$1@paganini.bofh.team> |
| In reply to | #403282 |
bart <bc@freeuk.com> wrote:
> On 18/10/2026 15:27, David Brown wrote:
>> On 18/10/2026 15:33, bart wrote:
>>> On 18/10/2026 12:22, David Brown wrote:
>
>>>> To me, that is just as much gibberish as the original C.
>>>
>>> That doesn't matter - the problem is not even knowing what it represents.
>>
>> That is, shall we say, a strange attitude. Gibberish (since that seems
>> to be the preferred term here) is gibberish, no matter the language or
>> representation, and is equally meaningless and useless.
>
> 'Gibberish' here refers to the representation, whether the type being
> described is made-up nonsense or real.
>
> You may want to know what some complex type is for many reasons, you
> don't necessarily need to understand what it means or why it was used.
>
> (For example I might come across a type in a C API that I want to
> convert to another language.)
You say that you had commercial product, but you are apparently not
aware of basic marketing principles. You do not win in the market
by making easy switch from your product to competitor product. You
may want to make it easy to switch _to_ your product. But you want
to make switching to competing products as hard as possible. Of
course there are constraints on this, in the process you do not want
to deteriorate quality of your product too much and you have finite
development resources.
Judging on this criteria you should admit that C is pretty good:
people wrote translators from various languages to C, but there
seem to be no success story going in opposite direction. C++
managed to take over nontrivial part of market previously occupied
by C, but they did this by embedding largish subset of C and by
massvie pileup of extra features.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-10-19 15:00 +0100 |
| Message-ID | <11b57p2$246h2$1@dont-email.me> |
| In reply to | #403308 |
On 19/10/2026 09:46, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> On 18/10/2026 15:27, David Brown wrote: >>> On 18/10/2026 15:33, bart wrote: >>>> On 18/10/2026 12:22, David Brown wrote: >> >>>>> To me, that is just as much gibberish as the original C. >>>> >>>> That doesn't matter - the problem is not even knowing what it represents. >>> >>> That is, shall we say, a strange attitude. Gibberish (since that seems >>> to be the preferred term here) is gibberish, no matter the language or >>> representation, and is equally meaningless and useless. >> >> 'Gibberish' here refers to the representation, whether the type being >> described is made-up nonsense or real. >> >> You may want to know what some complex type is for many reasons, you >> don't necessarily need to understand what it means or why it was used. >> >> (For example I might come across a type in a C API that I want to >> convert to another language.) > > You say that you had commercial product, but you are apparently not > aware of basic marketing principles. You do not win in the market > by making easy switch from your product to competitor product. You > may want to make it easy to switch _to_ your product. But you want > to make switching to competing products as hard as possible. Of > course there are constraints on this, in the process you do not want > to deteriorate quality of your product too much and you have finite > development resources. > > Judging on this criteria you should admit that C is pretty good: > people wrote translators from various languages to C, but there > seem to be no success story going in opposite direction. There are lots of reasons why not. C is popular as a compiler target because it is lower level than the source language. It has a weak type system which is easy to circumvent. It has 'goto'! (Many languages don't) There are well established, ubiquitous optimising compilers for it. Now, what would be the reasons for going the other way? There aren't any! (Well, some languages may have a feature to translate C programs into their syntax so that development can proceed in the new language. But the start point here is not C code being used for development, with some other HLL as an intermediate form.) So for that purpose, C is probably the most practical of current HLLs. Even if it is still not ideal and there are features which are awkward to express as C. C's UBs also get in the way. I've tried several times myself both with high-level and low-level generated C. (However, as a target language, I recently tried my own for that purpose, and it worked perfectly! Some features such as out-of-order definitions made it easier than C. Of course, my product does not have optimising compilers and very limited targets, due to not having an army of 1000s taking care of that as happens with C. But it shows that the creating such a suitable language design is not hard.) > C++ > managed to take over nontrivial part of market previously occupied > by C, but they did this by embedding largish subset of C and by > massvie pileup of extra features. So why IS C still around given that C++ compiler can build C programs, more or less?
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-10-19 16:55 +0100 |
| Message-ID | <11b5eic$26rua$1@dont-email.me> |
| In reply to | #403321 |
On 19/10/2026 15:00, bart wrote: > > So why IS C still around given that C++ compiler can build C programs, > more or less? Because it's typically less. I see C and C++ as very different.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-20 02:40 +0000 |
| Message-ID | <11b6kav$2kohl$1@dont-email.me> |
| In reply to | #403308 |
On Mon, 19 Oct 2026 08:46:58 -0000 (UTC), Waldek Hebisch wrote: > You do not win in the market by making easy switch from your product > to competitor product. You may want to make it easy to switch _to_ > your product. But you want to make switching to competing products > as hard as possible. “Vendor lock-in” -- that’s the old proprietary-software model. Customers are growing savvy to that sort of trick, which is why open-source software has become so popular. The most insidious form isn’t so much about the software, but about the proprietary data formats. If competitors’ software cannot read files containing the customers’ precious data accumulated over years of using a product, then the customer cannot switch to the competitor, even if they wanted to.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 17:24 +0300 |
| Message-ID | <20261018172446.00002d43@yahoo.com> |
| In reply to | #403261 |
On Sun, 18 Oct 2026 13:22:52 +0200 David Brown <david.brown@hesbynett.no> wrote: > > To me, that is just as much gibberish as the original C. No syntax > is going to make sense of it - no amount of "ref" or "func" or > pre-fix array notation will help. > [O.T.] Prefix array notation would not. But postfix * notation would, somewhat. It would be interesting to find out why designers of C, or of one of its ancestors decided that * as prefix is preferable to * as postfix. Were they afraid of confusion with usage of * as multiplication? Probably not, because confusion can arise about equally both for prefix and for postfix.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 16:58 +0200 |
| Message-ID | <11b2mqu$16mof$3@dont-email.me> |
| In reply to | #403271 |
On 18/10/2026 16:24, Michael S wrote: > On Sun, 18 Oct 2026 13:22:52 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> To me, that is just as much gibberish as the original C. No syntax >> is going to make sense of it - no amount of "ref" or "func" or >> pre-fix array notation will help. >> > > [O.T.] > Prefix array notation would not. But postfix * notation would, somewhat. > I can agree that notational changes might make it marginally easier to understand complex declarations - or mean that declarations could be marginally more complex while still being easily understood. But nothing can make Bart's exaggerated examples meaningful. > It would be interesting to find out why designers of C, or of one of its > ancestors decided that * as prefix is preferable to * as postfix. > Were they afraid of confusion with usage of * as multiplication? > Probably not, because confusion can arise about equally both for prefix > and for postfix. > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 18:26 +0300 |
| Message-ID | <20261018182627.00001934@yahoo.com> |
| In reply to | #403277 |
On Sun, 18 Oct 2026 16:58:38 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 18/10/2026 16:24, Michael S wrote: > > On Sun, 18 Oct 2026 13:22:52 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> > >> To me, that is just as much gibberish as the original C. No syntax > >> is going to make sense of it - no amount of "ref" or "func" or > >> pre-fix array notation will help. > >> > > > > [O.T.] > > Prefix array notation would not. But postfix * notation would, > > somewhat. > > I can agree that notational changes might make it marginally easier > to understand complex declarations - or mean that declarations could > be marginally more complex while still being easily understood. But > nothing can make Bart's exaggerated examples meaningful. > > > It would be interesting to find out why designers of C, or of one > > of its ancestors decided that * as prefix is preferable to * as > > postfix. Were they afraid of confusion with usage of * as > > multiplication? Probably not, because confusion can arise about > > equally both for prefix and for postfix. > > > > I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" > and similar expressions, felt "(p++)* = (q++)*" was unclear? > Why would it require parentheses?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-18 18:11 +0200 |
| Message-ID | <11b2r36$3pvda$8@dont-email.me> |
| In reply to | #403280 |
On 2026-10-18 17:26, Michael S wrote: > On Sun, 18 Oct 2026 16:58:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 18/10/2026 16:24, Michael S wrote: [...] >>> It would be interesting to find out why designers of C, or of one >>> of its ancestors decided that * as prefix is preferable to * as >>> postfix. Because it is more "natural" when read, easier to grasp? Simpler for compilers? More consistent if all other, especially standard operators known from daily use are used in prefix-form (-5, +42, !false, ~bitset) in expressions? I don't recall to have used any language with infix-expressions that would have their monadic operators defined in postfix form. The only exception was "C" (and C-oriented languages) with their special case of post-increment/post-decrement operators. (Think also about the quirk in C++ to define monadic postfix operators that require a syntactic dummy type argument). (In low-level RPN systems it may appear more "natural", but that just aside.) >>> Were they afraid of confusion with usage of * as >>> multiplication? Probably not, because confusion can arise about >>> equally both for prefix and for postfix. >> >> I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" >> and similar expressions, felt "(p++)* = (q++)*" was unclear? > > Why would it require parentheses? Not necessarily (I think). Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-18 19:32 +0300 |
| Message-ID | <20261018193201.00000b13@yahoo.com> |
| In reply to | #403283 |
On Sun, 18 Oct 2026 18:11:18 +0200 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2026-10-18 17:26, Michael S wrote: > > On Sun, 18 Oct 2026 16:58:38 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/10/2026 16:24, Michael S wrote: > [...] > >>> It would be interesting to find out why designers of C, or of one > >>> of its ancestors decided that * as prefix is preferable to * as > >>> postfix. > > Because it is more "natural" when read, easier to grasp? IMHO, no. >Simpler for compilers? 100% no. > More consistent if all other, especially standard > operators known from daily use are used in prefix-form (-5, +42, > !false, ~bitset) in expressions? Unary * is more similar in function to postfix operators like [] and () than to those you mentioned. > > I don't recall to have used any language with infix-expressions > that would have their monadic operators defined in postfix form. I am a Bear of Very Little Brain, and long words Bother Me. By chance, did you never use Pascal? > The only exception was "C" (and C-oriented languages) with their > special case of post-increment/post-decrement operators. (Think > also about the quirk in C++ to define monadic postfix operators > that require a syntactic dummy type argument). (In low-level RPN > systems it may appear more "natural", but that just aside.) > > >>> Were they afraid of confusion with usage of * as > >>> multiplication? Probably not, because confusion can arise about > >>> equally both for prefix and for postfix. > >> > >> I don't know why it is prefix. Maybe they were keen on "*p++ = > >> *q++" and similar expressions, felt "(p++)* = (q++)*" was unclear? > >> > > > > Why would it require parentheses? > > Not necessarily (I think). > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 15:44 +0200 |
| Message-ID | <11b56s8$1kr9u$2@dont-email.me> |
| In reply to | #403284 |
On 2026-10-18 18:32, Michael S wrote: > On Sun, 18 Oct 2026 18:11:18 +0200 > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-10-18 17:26, Michael S wrote: >>> On Sun, 18 Oct 2026 16:58:38 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 18/10/2026 16:24, Michael S wrote: >> [...] >>>>> It would be interesting to find out why designers of C, or of one >>>>> of its ancestors decided that * as prefix is preferable to * as >>>>> postfix. >> >> Because it is more "natural" when read, easier to grasp? > > IMHO, no. Okay, if you think so. > >> Simpler for compilers? > > 100% no. I've read that would be a, albeit small, existing factor (when resolving ambiguities or some such; but I don't recall details). Anyway, I just want to mention some existing purported arguments, so I take your word as granted. > >> More consistent if all other, especially standard >> operators known from daily use are used in prefix-form (-5, +42, >> !false, ~bitset) in expressions? > > Unary * is more similar in function to postfix operators like [] and () > than to those you mentioned. I don't know how you come to that opinion. Personally I've learned the concepts in abstract, non-language-specific forms as 'deref'; "deref p" not "p deref"; to me the former looks more natural, but we can agree that this may be just our personal preferences). (A less low-level language will ideally anyway abstract from any explicit dereferentiation, but since we're speaking about "C" I'm not expanding further on that.) > >> >> I don't recall to have used any language with infix-expressions >> that would have their monadic operators defined in postfix form. > > I am a Bear of Very Little Brain, and long words Bother Me. (If that quote is important for your argument, please explain.) > > By chance, did you never use Pascal? Oh, yes, how could I forget that! (I stand corrected.) - I suppose it's because I considered that more an "accessor" than an operator (like the array or struct selectors); that's also why it's often not listed in Pascal's operator precedence tables. - So thanks for the reminder. Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-19 22:35 +0300 |
| Message-ID | <20261019223538.00006521@yahoo.com> |
| In reply to | #403318 |
On Mon, 19 Oct 2026 15:44:40 +0200 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2026-10-18 18:32, Michael S wrote: > > On Sun, 18 Oct 2026 18:11:18 +0200 > > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > >> > >> I don't recall to have used any language with infix-expressions > >> that would have their monadic operators defined in postfix form. > > > > I am a Bear of Very Little Brain, and long words Bother Me. > > (If that quote is important for your argument, please explain.) > Translation: 1. I have no idea what unary * has to do with infix-expressions 2. I don't appriciate use of the term "infix-expression" instead of more common (in context of description of C and similar languages) term 'binary operators'. 3. I don't know what "monadic operators defined in postfix form" means and have no plans to look for the meaning
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 23:27 +0200 |
| Message-ID | <11b61v8$1kr9u$6@dont-email.me> |
| In reply to | #403336 |
On 2026-10-19 21:35, Michael S wrote: > On Mon, 19 Oct 2026 15:44:40 +0200 > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > >> On 2026-10-18 18:32, Michael S wrote: >>> On Sun, 18 Oct 2026 18:11:18 +0200 >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>> >>>> I don't recall to have used any language with infix-expressions >>>> that would have their monadic operators defined in postfix form. >>> >>> I am a Bear of Very Little Brain, and long words Bother Me. >> >> (If that quote is important for your argument, please explain.) >> > > Translation: > 1. I have no idea what unary * has to do with infix-expressions > 2. I don't appriciate use of the term "infix-expression" instead of more > common (in context of description of C and similar languages) term > 'binary operators'. > 3. I don't know what "monadic operators defined in postfix form" means > and have no plans to look for the meaning > I'm sorry, these are (AFAICT) common terms, and I thought obvious. So let me explain and amend with more text and examples... Point 1. - I gave the hint that in languages that support RPN (= Reverse Polish Notation) things like monadic postfix operators (= having just _one_ argument applied _after_ the operator) are the natural way of writing expressions. Less so in languages, which are the majority since decades, that support expressions with infix operators (= the operator arguments left and right of the operator). Point 2. - A "binary operator" may be the '*' in the expressions a * b typical infix notation (with parenthesis for precedence) a b * RPN * a b PN (Polish Notation) A "binary operator" is something different from an "infix expression" (the first one of the three; the others are RPN and PN examples). That's why I took the appropriate term to explain what I intended to explain. Point 3. - "monadic" (see point 1). Applying to postfix form is best explained on another example; assume RPN a - monadic (unary) minus (on one argument) a b - dyadic (binary) minus (difference of two arguments) Hope the terms are clear now. Now consider our original case, e.g. a * *b ... multiply and dereference a - -b ... subtract and negate as soon as we parse the second operator we know its kind. With postfix operators we'd have (assuming same semantics but with postfix operators) a * b * ... now what is the second '*' at that point of parsing? a - b - ... we don't expect that second '-' to be a negation. The compilers can handle every variant. For the users it's different; usually they seem to prefer unary operators to be prefixed (YMMV). The question (concerning "C") was; would it have been "better" (in any respect) if the dereferencing operator would have been defined in "C" as postfix operator (as you seem to prefer). Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-19 23:29 +0200 |
| Message-ID | <11b624i$1kr9u$7@dont-email.me> |
| In reply to | #403338 |
Darn typo... On 2026-10-19 23:27, Janis Papanagnou wrote: > Point 1. - I gave the hint that in languages that support RPN > (= Reverse Polish Notation) things like monadic postfix operators > (= having just _one_ argument applied _after_ the operator) are the (= having just _one_ argument and operator applied _after_ the argument) > Janis >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-20 00:57 +0300 |
| Message-ID | <20261020005720.000026c2@yahoo.com> |
| In reply to | #403338 |
On Mon, 19 Oct 2026 23:27:03 +0200 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2026-10-19 21:35, Michael S wrote: > > On Mon, 19 Oct 2026 15:44:40 +0200 > > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > > > >> On 2026-10-18 18:32, Michael S wrote: > >>> On Sun, 18 Oct 2026 18:11:18 +0200 > >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > >>>> > >>>> I don't recall to have used any language with infix-expressions > >>>> that would have their monadic operators defined in postfix form. > >>>> > >>> > >>> I am a Bear of Very Little Brain, and long words Bother Me. > >> > >> (If that quote is important for your argument, please explain.) > >> > > > > Translation: > > 1. I have no idea what unary * has to do with infix-expressions > > 2. I don't appriciate use of the term "infix-expression" instead of > > more common (in context of description of C and similar languages) > > term 'binary operators'. > > 3. I don't know what "monadic operators defined in postfix form" > > means and have no plans to look for the meaning > > > > I'm sorry, these are (AFAICT) common terms, and I thought obvious. > So let me explain and amend with more text and examples... > > Point 1. - I gave the hint that in languages that support RPN > (= Reverse Polish Notation) things like monadic postfix operators > (= having just _one_ argument applied _after_ the operator) are the > natural way of writing expressions. Less so in languages, which are > the majority since decades, that support expressions with infix > operators (= the operator arguments left and right of the operator). > > Point 2. - A "binary operator" may be the '*' in the expressions > a * b typical infix notation (with parenthesis for precedence) > a b * RPN > * a b PN (Polish Notation) > > A "binary operator" is something different from an "infix expression" > (the first one of the three; the others are RPN and PN examples). > That's why I took the appropriate term to explain what I intended to > explain. > O.k. > Point 3. - "monadic" (see point 1). Applying to postfix form is best > explained on another example; assume RPN > a - monadic (unary) minus (on one argument) > a b - dyadic (binary) minus (difference of two arguments) > > Hope the terms are clear now. Now consider our original case, e.g. > > a * *b ... multiply and dereference > a - -b ... subtract and negate > > as soon as we parse the second operator we know its kind. With postfix > operators we'd have (assuming same semantics but with postfix > operators) > > a * b * ... now what is the second '*' at that point of parsing? If C was as strongly typed from the beginning as it ended up in the 2nd half of the 70s then it would make sense to use postfix . (dot) instead of prefix * as dereference operator. Unfortunately, in early stage of development C was almost untyped, so something like that was out of question. > a - b - ... we don't expect that second '-' to be a negation. > > The compilers can handle every variant. For the users it's different; > usually they seem to prefer unary operators to be prefixed (YMMV). > > The question (concerning "C") was; would it have been "better" (in any > respect) if the dereferencing operator would have been defined in "C" > as postfix operator (as you seem to prefer). > > Janis > It would be certainly better in the context of type declarators. By now mixing postfix with prefix is their most confusing part. I have no strong opinion about advantages and disadvantages of postfix in context of use of * in expressions, but suspect that in this context the postfix will slightly reduce the need for parenthesis.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-20 00:55 +0200 |
| Message-ID | <11b674f$1l24u$1@dont-email.me> |
| In reply to | #403341 |
On 2026-10-19 23:57, Michael S wrote: > On Mon, 19 Oct 2026 23:27:03 +0200 > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > [...] > > If C was as strongly typed from the beginning as it ended up in the 2nd > half of the 70s then it would make sense to use postfix . (dot) instead > of prefix * as dereference operator. Well, in "C" we have (for pointers) at least "p->v" as shortcut of "(*p).v" which is good to have! But that '->' is a dyadic operator and makes (for this specific case) the deref operator unnecessary. We still need it for other purposes, like the often cited "*a++ = *b++". I don't see how the situation would have been different in the 1970's, though. But nevermind. (Other languages might not even impose the differentiation and just have "p.v" and "s.v" for both, access of components referenced by pointer or direct struct access. Yet other languages do any 'deref' implicitly.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-20 10:25 +0200 |
| Message-ID | <11b78i5$2m8c9$4@dont-email.me> |
| In reply to | #403338 |
On 19/10/2026 23:27, Janis Papanagnou wrote:
> On 2026-10-19 21:35, Michael S wrote:
>> On Mon, 19 Oct 2026 15:44:40 +0200
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> On 2026-10-18 18:32, Michael S wrote:
>>>> On Sun, 18 Oct 2026 18:11:18 +0200
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>>>
>>>>> I don't recall to have used any language with infix-expressions
>>>>> that would have their monadic operators defined in postfix form.
>>>>
>>>> I am a Bear of Very Little Brain, and long words Bother Me.
>>>
>>> (If that quote is important for your argument, please explain.)
>>>
>>
>> Translation:
>> 1. I have no idea what unary * has to do with infix-expressions
>> 2. I don't appriciate use of the term "infix-expression" instead of more
>> common (in context of description of C and similar languages) term
>> 'binary operators'.
>> 3. I don't know what "monadic operators defined in postfix form" means
>> and have no plans to look for the meaning
>>
>
> I'm sorry, these are (AFAICT) common terms, and I thought obvious.
I am afraid your terminology is further from common use than you
thought. ("Common use" of course depends on the context of the user -
we are in the context of C programmers.) Your posts can be clearer if
you use appropriate terminology.
> So let me explain and amend with more text and examples...
>
> Point 1. - I gave the hint that in languages that support RPN
> (= Reverse Polish Notation) things like monadic postfix operators
> (= having just _one_ argument applied _after_ the operator) are the
> natural way of writing expressions. Less so in languages, which are
> the majority since decades, that support expressions with infix
> operators (= the operator arguments left and right of the operator).
>
RPN - Reverse Polish Notation - is certainly a well-known term, though
the abbreviation might seem out of place. "Postfix" is the term most
obvious in the context of C, as that is the term used in the standards.
And while "x y +" is clearly RPN, "x *" is not - it could be part of an
infix expression, or a unary postfix operator.
"Monadic" /can/ refer to single argument functions or operators. But it
can also mean something completely different - monadic operations are
operations that work on "packaged" types that unpack the value, apply a
function, and pack it in again. There is nothing of that kind in C (the
language or standard library), but it is becoming a familiar term for
users of C++ and is well-established in many other languages.
The C standard using "unary" for single-argument operators.
Similarly, "binary" is the normal term for two-argument operators, not
"dyadic". (Though I don't think "dyadic" has any other common meanings.)
> Point 2. - A "binary operator" may be the '*' in the expressions
> a * b typical infix notation (with parenthesis for precedence)
> a b * RPN
Normally known as "postfix", especially in C.
> * a b PN (Polish Notation)
There is no term "Polish Notation" - except as occasionally used to mean
/postfix/ as a short form of "Reverse Polish Notation". RPN was
invented, or at least popularised, by the Polish logician Jan
Łukasiewicz (I admit to looking that up on Wikipedia!). There is no
"PN" opposite.
>
> A "binary operator" is something different from an "infix expression"
> (the first one of the three; the others are RPN and PN examples).
> That's why I took the appropriate term to explain what I intended to
> explain.
Yes, binary operators can be prefix, infix or postfix.
>
> Point 3. - "monadic" (see point 1). Applying to postfix form is best
> explained on another example; assume RPN
> a - monadic (unary) minus (on one argument)
Or, as the C world calls it, a postfix unary operator.
> a b - dyadic (binary) minus (difference of two arguments)
>
Or, as the C world calls it, a syntax error or a refugee from
comp.lang.forth.
> Hope the terms are clear now. Now consider our original case, e.g.
>
> a * *b ... multiply and dereference
> a - -b ... subtract and negate
>
> as soon as we parse the second operator we know its kind. With postfix
> operators we'd have (assuming same semantics but with postfix operators)
>
> a * b * ... now what is the second '*' at that point of parsing?
> a - b - ... we don't expect that second '-' to be a negation.
>
> The compilers can handle every variant. For the users it's different;
> usually they seem to prefer unary operators to be prefixed (YMMV).
>
> The question (concerning "C") was; would it have been "better" (in any
> respect) if the dereferencing operator would have been defined in "C"
> as postfix operator (as you seem to prefer).
>
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-20 16:56 +0200 |
| Message-ID | <11b7vev$1l24u$2@dont-email.me> |
| In reply to | #403371 |
On 2026-10-20 10:25, David Brown wrote:
> On 19/10/2026 23:27, Janis Papanagnou wrote:
>> On 2026-10-19 21:35, Michael S wrote:
>>> [...]
>>
>> I'm sorry, these are (AFAICT) common terms, and I thought obvious.
>
> I am afraid your terminology is further from common use than you
> thought.
I'm afraid you are wrong here; in several ways. I'll expand below.
> ("Common use" of course depends on the context of the user -
> we are in the context of C programmers.) Your posts can be clearer if
> you use appropriate terminology.
>
>
>> So let me explain and amend with more text and examples...
>>
>> Point 1. - I gave the hint that in languages that support RPN
>> (= Reverse Polish Notation) things like monadic postfix operators
>> (= having just _one_ argument applied _after_ the operator) are the
>> natural way of writing expressions. Less so in languages, which are
>> the majority since decades, that support expressions with infix
>> operators (= the operator arguments left and right of the operator).
>>
>
> RPN - Reverse Polish Notation - is certainly a well-known term, though
> the abbreviation might seem out of place.
I don't know why you think it would be "out of place". Since I gave
an explanation that made use of that concept I named it, and since
Michael had expressed difficulties with some of my (what I thought
to be commonly known, even here) terms I presented "RPN" with its
explicit meaning as you see above. (It's IMO good style to "explain"
acronyms when first used; but sadly - especially also here! - we
rarely see that, so I find it strange that you mention that at all.)
> "Postfix" is the term most
> obvious in the context of C, as that is the term used in the standards.
It's not about being obvious in context of C, it's about accuracy
of the used term in the context of my conceptual explanations.
(If I'd intended to explain something concerning the C-definition I
probably might have used the C-standard term. But I was explaining
something principle and used standard and common CS terminology.)
>
> And while "x y +" is clearly RPN, "x *" is not - it could be part of an
> infix expression, or a unary postfix operator.
Sure. If you reinspect my post you'll see that I used that term in
context of "x y +" and not in context of "a * b * ..." that I used
later. So your comment here is just unnecessary noise and void.
>
> "Monadic" /can/ refer to single argument functions or operators.
In CS I learned that "monadic" very specifically has the meaning I
used it for. - /Britannica/ (for example) [also] explains:
"Monadic and dyadic operators refer to the number of arguments
or operands an operator takes"
As an intermediate _general_ note; please accept that I use common
CS terms if I'm speaking about programming languages in general and
about design concepts. - I know and acknowledge that such terms are
often redefined (for specific contexts) or regularly misused. Don't
expect me to deliberately blur my language to express something for
an audience that *might* not have knowledge beyond "C". (I'd think
most of the audience here knows the CS terminology, though. If not
then I'll be glad to explain.)
> But it
> can also mean something completely different - monadic operations are
> operations that work on "packaged" types that unpack the value, apply a
> function, and pack it in again. There is nothing of that kind in C (the
> language or standard library), but it is becoming a familiar term for
> users of C++ and is well-established in many other languages.
(I know "many other languages" but don't recall to have seen mentioned
that word in another language with a meaning other than explained. So
I cannot know that it was given another meaning in some other special
area (like "packed types"). But I'd also expect that IT people at least
know the common CS terms.)
>
> The C standard using "unary" for single-argument operators.
>
> Similarly, "binary" is the normal term for two-argument operators, not
> "dyadic". (Though I don't think "dyadic" has any other common meanings.)
If we compare in discussions monadic and dyadic operators it would be
more a terminology issue with "unary" since the counterpart would then
be "binary", and "binary" is a homonymous word in that area and also on
that explanation level. - I prefer a most fitting choice of words.
And I'm sorry if some cannot follow my post because of that. But I'm
willing to explain if some terms are not known to some here; just ask.
>
>> Point 2. - A "binary operator" may be the '*' in the expressions
>> a * b typical infix notation (with parenthesis for precedence)
>> a b * RPN
>
> Normally known as "postfix", especially in C.
"Normally" I've seen that notation called RPN sometimes also as postfix
notation. (Please don't try to teach a duck swimming. And I suggest to
not join the club of folks who generalize based on opinions with words
like "normally".)
>
>> * a b PN (Polish Notation)
>
> There is no term "Polish Notation" -
My academic education as well as some [well reputed] online resources
disagree with you. (I wonder why you didn't check your _opinion_ here!)
> except as occasionally used to
> mean /postfix/ as a short form of "Reverse Polish Notation". RPN was
> invented, or at least popularised, by the Polish logician Jan
> Łukasiewicz (I admit to looking that up on Wikipedia!). There is no
> "PN" opposite.
Oh, so you have just missed it! - Retry...
https://en.wikipedia.org/wiki/Polish_notation
And next time better stay quiet instead of trying to play the smartass
without need! (It's really not necessary to post as much as you do.)
>
>>
>> A "binary operator" is something different from an "infix expression"
>> (the first one of the three; the others are RPN and PN examples).
>> That's why I took the appropriate term to explain what I intended to
>> explain.
>
> Yes, binary operators can be prefix, infix or postfix.
You don't need to confirm that. (It's common knowledge.)
> [ snip rest ]
(I've got tired and bored about your post.) :-/
But thanks for making it obvious that I cannot expect common and long
existing CS terms to be generally understood here.
I admit, that I might have made a wrong assumption about CS knowledge
here; before your post I thought it were just one or two individuals.
(Now my guess would be that it could be three or four individuals.)
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-20 17:32 +0200 |
| Message-ID | <11b81in$2m8c9$7@dont-email.me> |
| In reply to | #403380 |
On 20/10/2026 16:56, Janis Papanagnou wrote: > On 2026-10-20 10:25, David Brown wrote: >> On 19/10/2026 23:27, Janis Papanagnou wrote: >>> On 2026-10-19 21:35, Michael S wrote: >>>> [...] >>> >>> I'm sorry, these are (AFAICT) common terms, and I thought obvious. >> >> I am afraid your terminology is further from common use than you thought. > > I'm afraid you are wrong here; in several ways. I'll expand below. You don't need to be defensive here - I am trying to help you see /why/ your terms might not have been the best choices. It is not criticism of your post, just advice on your terminology so that it does not detract from understanding the content. (It is already clear that they were not good choices - Michael has long experience in software development of many types, and if they were not obvious to him in the context of your posts, they were not good terms to use.) You post a lot of interesting things. You made a post with unnecessary convoluted terminology that distracted from the content of your post, perhaps based on the particular usage of particular terms in the particular computer science courses you took. So my apologies for trying to be helpful! (And do look up "monads" and "monadic operations" - they are all the rage in many programming languages these days.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-18 21:11 +0200 |
| Message-ID | <11b35kn$1cn63$3@dont-email.me> |
| In reply to | #403280 |
On 18/10/2026 17:26, Michael S wrote: > On Sun, 18 Oct 2026 16:58:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/10/2026 16:24, Michael S wrote: >>> On Sun, 18 Oct 2026 13:22:52 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> >>>> To me, that is just as much gibberish as the original C. No syntax >>>> is going to make sense of it - no amount of "ref" or "func" or >>>> pre-fix array notation will help. >>>> >>> >>> [O.T.] >>> Prefix array notation would not. But postfix * notation would, >>> somewhat. >> >> I can agree that notational changes might make it marginally easier >> to understand complex declarations - or mean that declarations could >> be marginally more complex while still being easily understood. But >> nothing can make Bart's exaggerated examples meaningful. >> >>> It would be interesting to find out why designers of C, or of one >>> of its ancestors decided that * as prefix is preferable to * as >>> postfix. Were they afraid of confusion with usage of * as >>> multiplication? Probably not, because confusion can arise about >>> equally both for prefix and for postfix. >>> >> >> I don't know why it is prefix. Maybe they were keen on "*p++ = *q++" >> and similar expressions, felt "(p++)* = (q++)*" was unclear? >> > > Why would it require parentheses? > Maybe it would not - but I think perhaps "p++* = q++*" would be even less clear. But again, I have no idea here, and if dereferencing had been postfix, it might have had knock-on effects to other aspects of operator ordering or precedence.
[toc] | [prev] | [next] | [standalone]
Page 18 of 22 — ← Prev page 1 … 16 17 [18] 19 20 … 22 Next page →
Back to top | Article view | comp.lang.c
csiph-web