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-26 15:01 -0700 |
| Articles | 20 on this page of 537 — 25 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 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 20:53 -0700
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 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:47 -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 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:48 -0700
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-20 16:10 -0700
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 bart <bc@freeuk.com> - 2026-10-20 21:07 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 11:20 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:29 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 16:40 +0200
Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-20 23:33 +0300
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 00:01 +0100
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-20 17:05 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 12:45 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:04 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 13:21 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 11:26 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 12:33 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:21 +0200
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 15:41 +0100
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:36 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 15:37 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 17:22 +0100
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 17:21 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 19:04 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:38 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:36 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:36 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 23:10 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 22:55 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 17:19 +0200
Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-21 19:17 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 20:49 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:56 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 19:24 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 21:30 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 21:44 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-20 23:43 +0100
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 00:56 +0000
Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-21 02:39 +0100
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:55 -0700
Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-21 07:22 +0000
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 01:56 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:10 +0200
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 14:17 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 13:22 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 17:29 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 18:43 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-21 13:02 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 08:57 +0200
Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-22 12:56 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 17:00 +0000
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-22 16:54 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-22 21:09 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-22 12:46 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-23 09:37 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-23 14:21 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-23 22:40 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-23 18:33 -0700
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-24 22:26 +0000
Modelling self/this? (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-25 00:56 +0200
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-24 16:38 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-24 12:58 +0200
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-24 21:42 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-25 10:51 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-25 13:54 -0700
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-25 20:30 +0000
Re: Case-Sensitivity (was Re: Taming The Switch-Statement) Blaine <cactus_DAC@yahoo.com> - 2026-10-26 10:28 -0600
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-22 16:42 -0700
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-22 18:38 -0600
Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-23 04:23 +0000
Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-23 01:09 -0700
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 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-20 18:23 -0700
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-21 15:28 +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
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-21 11:19 +0200
Re: Taming The Switch-Statement Blaine <cactus_DAC@yahoo.com> - 2026-10-21 09:29 -0600
Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-22 00:33 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-22 09:51 +0200
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 13:07 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 12:11 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 13:20 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 14:16 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:03 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 16:32 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 16:42 +0000
Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-26 19:39 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 20:03 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 17:45 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 17:00 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:06 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:11 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 18:37 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 19:03 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 20:39 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 19:59 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:13 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 20:56 +0000
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:37 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:40 +0100
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:46 -0700
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 22:51 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:32 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-26 21:47 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:11 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:17 -0700
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:50 +0000
Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-26 23:37 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:01 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:28 +0100
Re: Taming The Switch-Statement fir <profesor.fir@gmail.com> - 2026-10-27 00:55 +0100
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-27 01:12 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 18:43 -0700
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 14:43 -0700
Re: Taming The Switch-Statement bartc <bc@freeuk.com> - 2026-10-26 21:55 +0000
Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-26 15:01 -0700
Page 20 of 27 — ← Prev page 1 … 18 19 [20] 21 22 … 27 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 15:10 +0200 |
| Message-ID | <11badkg$3uqp4$1@dont-email.me> |
| In reply to | #403390 |
On 21/10/2026 00:43, bart wrote:
> On 20/10/2026 22:44, Dan Cross wrote:
>> In article <11b8j17$3btus$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>> On 20/10/2026 20:24, Dan Cross wrote:
>>>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com>
>>>> wrote:
>>>
>>>> The point is that the name you chose is meaningless to anyone
>>>> other than you. What's a PCL? Phase Control Line? Printer
>>>> Command Language? Photon Compressor Loop?
>>>
>>> Within the context of that application then it would be clear. You're
>>> just being overly hostile.
>>
>> Not really. You are, I presume, posting that code to try and
>> make some kind of point about how "readable" it is. But it's
>> not readable unless you already know what it does.
>
> What it does not relevant. This is simply defining an array of T. But
> because T happens to be a function pointer, DB insists that an alias
> must be created, and a new name invented.
I did not "insist" or say that an alias "must" be created. I said
that's normally what you should do in real code, to make it clear,
readable and maintainable.
Note that I wrote (in regard to the "pcl" stuff) :
"""
I have no idea what your code is supposed to do, so I have no idea what
names would be good. Presumably you /do/ know what it is for - such as
what "pcl" means - so /you/ pick good names. Maybe "host_handler_fn" ?
"""
If "pcl" makes sense in the context of your code, that's fine - use it
in your names.
But don't use generic names where specific names impart useful
information. Don't re-use generic names because of a coincidence in the
underlying implementation - use names that make sense where they are used.
>
> Why? Probably because in C, the syntax for function pointers gets hairy.
No, this is all because I (and Dan) know how to write good code in a
clear (to appropriate readers) and maintainable manner. The syntax is
irrelevant. We appreciate that you find C's declaration syntax
confusing and difficult - I think that after the first two or three
hundred repetitions, it finally sank in. But please stop projecting
your weaknesses and prejudices onto other people. I do not name
function pointer types because of C's syntax - I name them because the
code is better in many ways when the types are named. I would do the
same in Pascal, Rust, Ada, or any other language, regardless of the syntax.
>
>> On the other hand, the code David posted _is_ readable, because
>> it uses the language to encode domain-specific information into
>> type names.
>
> Maybe we should create aliases for function signatures more often then,
> then we can encode that extra info.
>
> So that instead of, for example:
>
> void SomeFunc(int x, int y) {printf("%d %d\n", x, y);}
>
> you do:
>
> typedef void Take2Ints(int x, int y);
>
> Take2Ints SomeFunc {printf("%d %d\n", x, y);}
>
Maybe we should not. That is not helpful to code clarity. It is a
pointless generic name (showing that you /still/ do not understand the
fundamental matter of giving useful and informative names), and instead
of /giving/ useful additional information, it /hides/ details at the
point in the code where they are vital.
Now, if you had a concept of "Coordinate handler" that was expected to
receive an x, y pair and do something with them, then it is possible
that you would have a header file "coordinate_handlers.h" with :
typedef void Coordinate_Handler_Func(int x, int y);
and some related function declarations :
Coordinate_Handler_Func dummy_handler;
Coordinate_Handler_Func simple_printer;
Coordinate_Handler_Func fly_to_new_coordinates;
You are putting the emphasis here on what sort of usage you expect for
these functions, with the assumption that code using them knows how to
call them. This could be handy if you have another module that needs to
build an array or other data structure with these functions - it does
not care about the implementation details, and uses the function type
(or a pointer to the function type) without looking at its contents:
#include "coordinate_handlers.h"
size_t build_coordinate_handler_array(
Coordinate_Handler_Func * hs, size_t max_handlers)
{
assert(max_handlers >= 3);
hs[0] = &dummy_handler;
hs[1] = &simple_printer;
hs[2] = &fly_to_new_coordinates;
return 3;
}
A caller function might have :
#include "coordinate_handlers.h"
void call_handler(size_t handler_no, int x, int y) {
assert(handler_no < no_of_handlers);
Coordinate_Handler_Func h * handlers[handler_no];
h(x, y);
}
Handler implementations would be written normally :
#include "coordinate_handlers.h"
void simple_printer(int x, int y) {
printf("%d %d\n, x, y);
}
Then later when you decide to go to 3 dimensions, you need to change
code that calls these handlers, and you need to change the handler
implementations (and you'll get compile-time errors until you do), but
generic "in the middle" code like "build_coordinate_handler_array" is
unchanged.
But if the code also happened to need lots of functions for drawing
titles at x, y coordinates, it would have :
typedef void Title_Drawer_Func(int x, int y);
You would /not/ re-use the same typedef, just because the implementation
is the same, when the /purpose/ is different.
> If you have a suite of functions sharing the signature, then it might be
> a good idea. But funnily enough, you never see this being done.
>
Given that it is not remotely close to valid C, I don't think it is
particularly surprising.
> (I don't know if this is legal C; but it works fine with my compiler:
Your compiler is not a C compiler - it's a compiler for an undefined and
undocumented superset of an undefined and undocumented subset of an
undocumented version of C. If that's all you need, there's nothing
wrong with that - but what works or does not work with your compiler is
no indication of what is or is not "legal" C.
>
> c:\m>type fred.c
> #include <stdio.h>
>
> typedef void Take2Ints(int x, int y);
>
> Take2Ints SomeFunc{printf("%d %d\n", x, y);}
>
> int main(void) { SomeFunc(10, 20); }
>
> c:\m>bcc -r -q fred
> 10 20
>
> )
>
>> Yeah, you really just don't get it.
> One of us doesn't get it.
Exactly. I'm fairly sure you are alone here.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 14:17 +0200 |
| Message-ID | <11baah2$3te3v$1@dont-email.me> |
| In reply to | #403383 |
On 20/10/2026 21:24, Dan Cross wrote:
> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>> On 20/10/2026 09:01, David Brown wrote:
>>> On 19/10/2026 23:28, bart wrote:
>>
>>>> (Funny that when I suggest that nested loop breaks are uncommon,
>>>> everyone says I'm wrong! Some even write 200-line made-up examples to
>>>> prove their point.)
>>>
>>> I don't remember "everyone" saying you were wrong to say that nested
>>> loop breaks are uncommon - in fact, I don't remember /anyone/ saying
>>> that was wrong.
>>
>> (There was a LOT of antipathy towards my idea to fix the common case of
>> 'loop-break' clashing with 'switch-break', BECAUSE it did not fix the
>> problem of nested loop-break, which is uncommon, even though that wasn't
>> the aim.)
>
> Those are two different things. No one disagrees with you that
> "nested break from a switch inside of a loop" is relatively more
> common than other variants.
>
Quibble - that is not established to my satisfaction. I am not
convinced that wanting a nested break for "switch inside loop" is more
common than wanting it for "loop inside loop". So I neither agree nor
disagree with that claim. I don't, however, think it matters much -
both are situations that turn up sometimes in code, and definitive
answers are neither possible nor useful.
> Using that as an excuse not to provide a more general mechanism
> because you already have a proposal for the specific case is
> what I and others took you to task for. I find this ironic,
> since you rail against things in C that you do not like, citing
> the most ridiculous examples you can think of that do not show
> up in actual programs, yet for something where it is pointed out
> to you that your solution does not generalize, you claim that it
> does not need to because ... the general case rarely shows up in
> a real program.
>
>>>> There is no reason to abstract away that function pointer type.
>>>>
>>>> You probably do so in C /because/ the type involves * () and [] but
>>>> have somehow persuaded yourself that it just better that way.
>>>
>>> Do you hear that whooshing noise? It is the sound of the point flying
>>> far above your head.
>>>
>>> Here is an example of some sensible function typedefs, all from third-
>>> party code (so not my "peculiar" style)
>>>
>>> typedef void (*TimerCallbackFunction_t)( TimerHandle_t xTimer );
>>>
>>> TimerHandle_t xTimerCreate( const char * const pcTimerName,
>>> TickType_t xTimerPeriodInTicks,
>>> UBaseType_t uxAutoReload,
>>> void * pvTimerID,
>>> TimerCallbackFunction_t pxCallbackFunction );
>>>
>>> typedef void (*lwip_thread_fn)(void *arg);
>>> typedef void (*tcpip_init_done_fn)(void *arg);
>>> typedef void (*tcpip_callback_fn)(void *ctx);
>>> typedef void (* sys_timeout_handler)(void *arg);
>>> typedef void (*dns_found_callback)(const char *name,
>>> const ip_addr_t *ipaddr, void *callback_arg);
>>
>> This is the kind of C I find hard to read. There are lots of typedefs
>> but few uses of those typedefs that I can see, so I don't know how much
>> difference they make.
>
> You again missed the entire point. You may not see many uses
> of them, but as David says, the `typedef`s give you
> domain-specific *names* understandable to the programmer: a
> programmer can see the `sys_timeout_handler` type instantly know
> that this has a different function than the,
> `tcpip_callback_fn`, despite the having the same type.
Exactly.
>
> The other point is that the ridiculous examples you make up to
> illustrate your distaste for C declaration syntax basically do
> not appear in real programs.
>
>> [snip]
>> I've left in the regular parameter names, even though C doesn't need
>> them, but they are quite heavy - you don't really need those
>> Hungarian-style prefixes.)
>>
>> Well, I guess this buys you one thing: the parameter name for the last
>> parameter is to the right of its type, rather than be inside it. But a C
>> expert should not be fazed by that.
>>
>> Here is the same function as I might write it in an alternative syntax.
>>
>> I've kept the same names, but changed case-style and removed prefixes
>> and suffixes. I've capitalised user-type names:
>>
>> func TimerCreate( # (retain case if FFI import)
>> ichar timername,
>> Ticktype timerperiodinticks,
>> Ubasetype autoreload,
>> ref void timerid,
>> ref proc(Timerhandle) callbackfn)
>>
>> In this form, it's hard to see what benefit a typedef would give for
>> that last parameter; it is simple enough.
>
> What is your point? Do you have one? If you don't want to use
> C, don't use C.
>
> There are plenty of languages that can do this kind of thing
> that are not C and have syntax and semantics closer to what you
> seem to want. Here's an example in Rust:
>
> pub trait TimerHandle { ... }
>
> fn CreateTimer<T>(
> timer_name: &str,
> period: std::time::Duration,
> auto_reload: bool,
> timer_id: T,
> handler: fn(&dyn TimerHandle),
> ) -> Result<Timer<T>, TimerError>
>
> I didn't know what an `UBaseType_t` is, and while "autoreload"
> sounded pretty intuitive, I wasn't sure about the semantics, so
> I looked it up (the example comes from `FreeRTOS`). In this
> context, it is a boolean saying whether the timer should repeat
> with the given periodicity, or whether it is a one-shot.
FreeRTOS is written in C90 - a mistake, IMHO - and thus does not use
bool. Instead, it uses constants pdTRUE and pdFALSE of type
UBaseType_t. UBaseType_t is a type that is dependent on the target -
usually it is either 16-bit or 32-bit. But of course it doesn't matter
what the underlying types are - you use the typedef names, and the
documented constants.
>
> The timer_id is opaque to the timer, and it looks like it's used
> to facilitating the handler accessing timer-specific data. In
> C, passing it as a `void *` is used as a way to get a poor-man's
> overloading. But Rust has generics, I just made it generic over
> some type T.
FreeRTOS uses "void *" to mean "pointer to internal structure that you
shouldn't be messing with". It uses this far too often, and is, IMHO, a
poor design choice. (I also dislike the silly Hungarian naming.) I
would much preferred if there had been :
struct Internal_Timer_Struct;
typedef struct Internal_Timer_Struct * timer_id_t;
and then the parameter "timer_id_t timer_id". So in a re-write, it
would not be a generic. (You might choose to use a generic for the
handler function type, so that handler callbacks could have parameters
of other types, but not for the timer id.)
I am using these declarations from FreeRTOS (and LWIP) to demonstrate
the use of function typedefs in massively popular codebases, not to
claim FreeRTOS is a paradigm of C code design!
>
> If I were writing this from scratch in Rust, a language that has
> generics, closures, and so sum types, I'd do the whole thing
> differently; see the end for an example.
>
> But I digress. The point here is, Bart, that alternatives exist
> if you don't like C. You don't have to keep posting, over and
> over again, in comp.lang.c of all places, about how oh so
> terribly awful C is. If you don't want to program in C, simply
> don't program in C.
>
>>> Ask yourself why the typedefs are used. Look at the /names/. Those
>>> last four are all from the same network stack library, and are all
>>> typedefs for "void (*)(void*)".
>>
>> Until you mentioned it, I hadn't noticed. So typedef has done a good job
>> of hiding that useful fact! But looking more closely, it is the first
>> four of the last five.
>>
>> Let's take one:
>>
>> typedef void (*lwip_thread_fn)(void *arg);
>>
>> That 'arg' is not much use for a start (other than being a hint that
>> this particular (...) is where the parameters go).
>>
>> So, maybe this is used like this:
>>
>> void F(lwip_thread_fn lwip_thread_callback);
>
> I have no idea what you're trying to say here. The obvious (and
> honestly, excusable) syntax error aside, what is F? It's a
> function that, what, takes two function pointers?
>
> The type defined by `lwip_thread_fn` is a pointer to a function
> that takes a void pointer (`void *`) as its sole arugment, and
> returns `void` (that is, has no meaningful return value).
>
> Intuitively, the name implies that this is the function run as
> some thread, so we'd pass it to a thread creation function. The
> usual shape of those things is to give them a pointer to some
> function to run in the new thread, and a pointer to some
> arguments to be passed to that function.
Yes.
> For example:
>
> void
> whatever(void *argp)
> {
> struct Args *args = argp;
> while (keep_running()) {
> // Do the thing the thread is supposed to do.
> }
> thread_exit(SUCCESS);
> }
>
> thread_t *
> start_the_whatever_thread(void)
> {
> struct Args *args = malloc(sizeof(*args));
> if (args == NULL) abort();
> memset(args, 0, sizeof(*args));
> args->whatever = something();
> // etc...
> thread_t *thr = thread_create(whatever, args);
> if (thr == NULL) abort();
> return thr;
> }
>
> Something could start this as:
>
> thread_t *whatever_id = start_the_whatever_thread();
>
> At some point later, if you want to wait for the thread to
> exit, you'd run:
>
> (void)thread_join(whatever_id);
>
> Note this is decently complex behavior, but it's actually quite
> intuitive from the name and the type.
>
You have got a very clear picture here, much of it from the names of the
types. For a Rust programmer, you give a good impression of experience
with C :-)
The only mistake you made is that programmers working on systems using
FreeRTOS and the like, have a fear and loathing of "malloc", have never
heard of "abort()", and do not join our threads because they all run
until the power is switched off.
>> Here you have two identifiers imparting the sort kind of information; a
>> tautology.
>
> That's not what a tautology is.
>
>> If that function pointer pattern is common, or recurs in a suite of
>> functions, I might also have used a typedef, but with a common name.
>
> Then you loose the domain specificity; you can't tell from the
> name whether you need an LwIP thread, or a callback, or a
> something run in a different thread, or just a plain 'ol
> function you want to apply to run every now and again for a side
> effect.
Precisely.
>
>> Then only one would be needed, say:
>>
>> typedef void (*stack_callbackfn)(void);
>>
>> I might have done the same in that alternate syntax as it would start to
>> get cluttery: 'ref proc(ref void)', but also in order to define that
>> common pattern in one place.
>
> I dunno. Sounds like you have no idea what the code that David
> posted is meant to do. But that's a "you" problem.
>
>>>> Note that 'pcl' in my example /is/ a typedef; here it makes sense as
>>>> it is used in 100s of places. This function pointer occurs in only one
>>>> place.
>>>
>>> I'm sorry, I had mistaken you for a programmer who wanted to write good,
>>> clear programs. Naming things is not a shortcut to save keypresses.
>>
>> Isn't that one of the main uses of typedefs? So as to give a handy,
>> 'euphonious' one-token alias to an elaborate typedef.
>>
>> It also allows you to change the type in one place without having to
>> update hundreds of instances.
>>
>> It also allows the type to be opaque.
>
> The point is that the name you chose is meaningless to anyone
> other than you. What's a PCL? Phase Control Line? Printer
> Command Language? Photon Compressor Loop?
>
>> Saving keypresses is bonus benefit, but if it is shorter, then it can
>> also help readability as other critical elements are not overshadowed.
>>
>> So I'm not sure what objection you have to this particular use of it.
>
> Have you ever written a large program that was maintained by
> anyone other than yourself?
>
>> Here is the one place I do remember using typedef for a function pointer
>> (from an old project, not in C):
>>
>> type fnptr = ref proc
>>
>> repeat
>> (fnptr(pcptr^))^()
>> until stopped
>>
>> It's used as a cast, but reason I have it is because with simple cast
>> syntax, which is 'T(X)', the meaning without it would be ambiguous (a
>> grammar issue that I might fix one day).
>>
>> Rather than fallback to standard cast syntax (which is 'cast(X, T)'),
>> this was tidier.
>
> I can only guess at what this may mean. Hazarding a guess,
> `pcptr` is a "pointer to a program counter", which is a
> reference type to some type that represents some executable
> memory location in the program. You then have a loop that runs
> until "stopped" is true where you indirect the program counter
> pointer, cast it to a pointer to a function, and then invoke
> the function, right? One presumes you have the, "PC Pointer"
> because it changes over time, otherwise, you'd just give
> whatever it points to a name and call it.
>
> More generally, I fail to see what this is trying to
> demonstrate. If it's to show some sort of imagined superiority
> over C, I don't see it; that's sort of thing is easy enough to
> write:
>
> typedef void (*fnptr)(void);
>
> // Assume uintptr_t *pcptr is declared somewhere.
> do {
> ((fnptr)*pcptr)();
> } while (!stopped);
>
> E.g.,
>
> ```
> term% cat b.c
> #include <stdbool.h>
> #include <stddef.h>
> #include <stdint.h>
> #include <stdio.h>
>
> static void first(void);
>
> typedef void (*fnptr)(void);
> bool stopped = false;
> uintptr_t pc = (uintptr_t)first;
> uintptr_t *pcptr = &pc;
>
> void
> done(void)
> {
> printf("done\n");
> stopped = true;
> }
>
> void
> second(void)
> {
> printf("second\n");
> *pcptr = (uintptr_t)done;
> }
>
> void
> first(void)
> {
> printf("first\n");
> *pcptr = (uintptr_t)second;
> }
>
> void
> run(void)
> {
> do {
> ((fnptr)*pcptr)();
> } while (!stopped);
> }
>
> int
> main(void)
> {
> run();
> return 0;
> }
> term% gcc-16 -std=c11 -pedantic -o b b.c
> term% ./b
> first
> second
> done
> term%
> ```
Or just have :
fnptr pc = first;
fnptr *pcptr = &pc;
I don't see a need for "uintptr_t", except so that you have to have
casts like Bart had.
>
>>>> BTW what name would be given to such a function pointer type?
>>
>>> I have no idea what your code is supposed to do,
>>
>> It's a table of function pointers! All sharing the same signature.
>>
>> That's pretty generic. Is it really that hard to guess? You don't need
>> to know what they do, other than at some point they will be called as
>> handlertable[i](arg).
>
> That part is fine.
>
> What's utterly mystifying is what you are trying to show, if
> anything, by posting it. Is this supposed to prove some kind of
> point? Your code is not _a priori_ easier to understand than
> the equivalent C code; if anything, it is harder to understand
> because of your poorly chosen names.
>
> - Dan C.
>
> -->Rust implementation of Timers, mentioned above<--
>
> As mentioned above, if I were providing the FreeRTOS timers API
> in an alternative language, I'd write it differently from the
> start. In particular, I'd use an enumeration to describe the
> behavior with respect to repeating, and I'd use a closure to
> obviate the need for the opaque id. Something that isn't easy
> to express in the original API is a type of repeating timer that
> waits for the initial period, and then repeats with some
> different period.
>
> Something like this:
>
> ```rust
> pub mod timer {
> use std::sync::atomic::{AtomicBool, Ordering};
> use std::time::Duration;
>
> /// Errors that may occur when working with timers.
> #[derive(Clone, Copy, Debug)]
> pub enum Error {
> Running,
> CantStop,
> WontStop,
> }
>
> /// Describes the kind of a timer, as defined by its
> /// periodicity.
> ///
> /// A timer can either be a `OneShot` timer, which fires
> /// once, after its timeout expires, or it may be a Repeating
> /// timer, which will automatically reset after its handler
> /// is run and continue firing at the rate defined by the
> /// initial timeout, or it can be a periodic timer, that
> /// will fire the first time at the initial timeout, and
> /// then repeatedly a potentially different timeout. This
> /// use case can be simulated by a OneShot timer that
> /// creates a repeating Timer, but
> ///
> /// Once started, Repeating and Periodic timers continue
> /// firing until explicitly stopped.
> #[derive(Clone, Copy, Debug)]
> pub enum Kind {
> OneShot,
> Repeating,
> Periodic(Duration),
> }
>
> /// A named timer, that is handled by the given callback.
> pub struct Timer<'a, F> {
> pub name: &'a str,
> pub kind: Kind,
> pub timeout: Duration,
> callback: F,
> running: AtomicBool,
> // Whatever other innards...
> // ...
> }
>
> /// A read-only "view" into the timer.
> pub trait TimerView {
> fn name(&self) -> &str;
> fn kind(&self) -> Kind;
> fn timeout(&self) -> Duration;
> }
>
> impl<'a, F: Fn(&dyn TimerView)> Timer<'a, F> {
> /// Creates a new named timer of the given kind with an
> /// initial timeout. When the timeout expires, it will
> /// automatically invoke the given handler.
> pub fn new(
> name: &'a str,
> timeout: Duration,
> kind: Kind,
> callback: F,
> ) -> Timer<'a, F> {
> let running = AtomicBool::new(false);
> Self {
> name,
> kind,
> callback,
> timeout,
> running,
> }
> }
>
> /// Starts the timer.
> pub fn start(&self) -> Result<(), Error> {
> if self.running.swap(true, Ordering::AcqRel) {
> return Err(Error::Running);
> }
> self.arm(self.timeout)?;
> Ok(())
> }
>
> /// Stops the timer.
> ///
> /// Note that this inherently races with the timer firing,
> /// and a timer event that occurs while we are disabling
> /// the timer may still invoke `fired` after this returns.
> ///
> /// Callers are advised to determine definitively that
> /// there are no events pending for this timer before
> /// destroying the `Timer` object.
> pub fn stop(&self) -> Result<(), Error> {
> let was_running = self.running.swap(false, Ordering::AcqRel);
> if !was_running {
> return Err(Error::WontStop);
> }
> self.disarm();
> Ok(())
> }
>
> // Automatically called when the timeout fires.
> //
> // # Safety
> //
> // Nothing may be mutably borrowing a reference to the
> // Timer object when this is called.
> pub(super) unsafe fn fired(&self) -> Result<(), Error> {
> if !self.running.load(Ordering::Acquire) {
> return Ok(());
> }
> (self.callback)(self);
> match self.kind {
> Kind::OneShot => Ok(()),
> Kind::Repeating => self.arm(self.timeout),
> Kind::Periodic(period) => self.arm(period),
> }
> }
>
> // Arranges for `self.fired(self)` to be called when
> // the given timeout expires.
> fn arm(&self, timeout: Duration) -> Result<(), Error> {
> // Does whatever one does here to actually arm the
> // timer (e.g., calls a HAL to actually program a
> // physical timer to interrupt after the amount of
> // time specified by `Duration`, for example).
> // ...
> Ok(())
> }
>
> // Disables an armed timer, so that it does not fire
> // after this returns.
> fn disarm(&self) -> Result<(), Error> {
> // whatever one does here to disarm an active timer
> // ...
> Ok(())
> }
> }
>
> impl<F> TimerView for Timer<'_, F> {
> fn name(&self) -> &str { self.name }
> fn kind(&self) -> Kind { self.kind }
> fn timeout(&self) -> Duration { self.timeout }
> }
> }
> ```
>
> One might use this with something like,
>
> ```
> let value = 42;
> let cb = move |timer: &dyn timer::TimerView| {
> println!(
> "Timer '{}' fired; value is {} and duration was {} ms",
> timer.name(),
> value,
> timer.timeout().as_millis()
> );
> };
> let timeout = std::time::Duration::from_millis(100);
> let timer = timer::Timer::new("timer", timeout, timer::Kind::OneShot, &cb);
> timer.start().expect("Timer started");
> //... at some point the timer fires and prints,
> // 'Timer 'timer1' fired; value is 42 and duration was 100 ms'
> }
> ```
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 13:22 +0000 |
| Message-ID | <11baeai$959$1@reader2.panix.com> |
| In reply to | #403412 |
In article <11baah2$3te3v$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 20/10/2026 21:24, Dan Cross wrote:
>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>> [snip]
>>> (There was a LOT of antipathy towards my idea to fix the common case of
>>> 'loop-break' clashing with 'switch-break', BECAUSE it did not fix the
>>> problem of nested loop-break, which is uncommon, even though that wasn't
>>> the aim.)
>>
>> Those are two different things. No one disagrees with you that
>> "nested break from a switch inside of a loop" is relatively more
>> common than other variants.
>
>Quibble - that is not established to my satisfaction. I am not
>convinced that wanting a nested break for "switch inside loop" is more
>common than wanting it for "loop inside loop". So I neither agree nor
>disagree with that claim. I don't, however, think it matters much -
>both are situations that turn up sometimes in code, and definitive
>answers are neither possible nor useful.
Ok, that's fair; I shouldn't say "no one disagrees".
>> [snip]
>> There are plenty of languages that can do this kind of thing
>> that are not C and have syntax and semantics closer to what you
>> seem to want. Here's an example in Rust:
>>
>> pub trait TimerHandle { ... }
>>
>> fn CreateTimer<T>(
>> timer_name: &str,
>> period: std::time::Duration,
>> auto_reload: bool,
>> timer_id: T,
>> handler: fn(&dyn TimerHandle),
>> ) -> Result<Timer<T>, TimerError>
>>
>> I didn't know what an `UBaseType_t` is, and while "autoreload"
>> sounded pretty intuitive, I wasn't sure about the semantics, so
>> I looked it up (the example comes from `FreeRTOS`). In this
>> context, it is a boolean saying whether the timer should repeat
>> with the given periodicity, or whether it is a one-shot.
>
>FreeRTOS is written in C90 - a mistake, IMHO - and thus does not use
>bool. Instead, it uses constants pdTRUE and pdFALSE of type
>UBaseType_t. UBaseType_t is a type that is dependent on the target -
>usually it is either 16-bit or 32-bit. But of course it doesn't matter
>what the underlying types are - you use the typedef names, and the
>documented constants.
Thanks for the context. Your point that the underlying type
doesn't matter is salient: it's opaque to the programmer, but
99% of the time the programmer doesn't need to worry about the
details.
>> The timer_id is opaque to the timer, and it looks like it's used
>> to facilitating the handler accessing timer-specific data. In
>> C, passing it as a `void *` is used as a way to get a poor-man's
>> overloading. But Rust has generics, I just made it generic over
>> some type T.
>
>FreeRTOS uses "void *" to mean "pointer to internal structure that you
>shouldn't be messing with". It uses this far too often, and is, IMHO, a
>poor design choice. (I also dislike the silly Hungarian naming.) I
>would much preferred if there had been :
>
> struct Internal_Timer_Struct;
> typedef struct Internal_Timer_Struct * timer_id_t;
>
>and then the parameter "timer_id_t timer_id". So in a re-write, it
>would not be a generic. (You might choose to use a generic for the
>handler function type, so that handler callbacks could have parameters
>of other types, but not for the timer id.)
>
>I am using these declarations from FreeRTOS (and LWIP) to demonstrate
>the use of function typedefs in massively popular codebases, not to
>claim FreeRTOS is a paradigm of C code design!
Oh interesting; in this case, I had assumed it was treated as
a callback-specific type so one could plumb extra context into
the handler; the documentation I saw suggested it could be used
by the handler to disambiguate several timers reusing the same
handler function.
>> For example:
>>
>> [snip]
>>
>> Note this is decently complex behavior, but it's actually quite
>> intuitive from the name and the type.
>
>You have got a very clear picture here, much of it from the names of the
>types. For a Rust programmer, you give a good impression of experience
>with C :-)
I've been known to dabble.
>The only mistake you made is that programmers working on systems using
>FreeRTOS and the like, have a fear and loathing of "malloc", have never
>heard of "abort()", and do not join our threads because they all run
>until the power is switched off.
Ha, fair; that was just a made-up example, based on other thread
libraries I have used (in C). I didn't mean for it to be
interpreted strictly in the context of FreeRTOS! :-D
> [snip]
>
>Or just have :
>
> fnptr pc = first;
> fnptr *pcptr = &pc;
>
>I don't see a need for "uintptr_t", except so that you have to have
>casts like Bart had.
Yes. But I wanted to remain faithful to his original, to show
that one could write a more-or-less exact transliteration in C
that was extremely similar to his chosen syntax.
>> [Snip a bunch of Rust code; the point of which being that
>> bart need not complain about lack of an alternative to C]
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-21 17:29 +0200 |
| Message-ID | <11balos$1042$2@dont-email.me> |
| In reply to | #403416 |
On 21/10/2026 15:22, Dan Cross wrote:
> In article <11baah2$3te3v$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 20/10/2026 21:24, Dan Cross wrote:
>>> In article <11b7k22$2v8e5$1@dont-email.me>, bart <bc@freeuk.com> wrote:
>>>> [snip]
>>>> (There was a LOT of antipathy towards my idea to fix the common case of
>>>> 'loop-break' clashing with 'switch-break', BECAUSE it did not fix the
>>>> problem of nested loop-break, which is uncommon, even though that wasn't
>>>> the aim.)
>>>
>>> Those are two different things. No one disagrees with you that
>>> "nested break from a switch inside of a loop" is relatively more
>>> common than other variants.
>>
>> Quibble - that is not established to my satisfaction. I am not
>> convinced that wanting a nested break for "switch inside loop" is more
>> common than wanting it for "loop inside loop". So I neither agree nor
>> disagree with that claim. I don't, however, think it matters much -
>> both are situations that turn up sometimes in code, and definitive
>> answers are neither possible nor useful.
>
> Ok, that's fair; I shouldn't say "no one disagrees".
And I didn't say I /did/ disagree - merely that I don't feel I have the
information to disagree or agree.
We all over-generalise, and that's always bad!
>
>>> [snip]
>>> There are plenty of languages that can do this kind of thing
>>> that are not C and have syntax and semantics closer to what you
>>> seem to want. Here's an example in Rust:
>>>
>>> pub trait TimerHandle { ... }
>>>
>>> fn CreateTimer<T>(
>>> timer_name: &str,
>>> period: std::time::Duration,
>>> auto_reload: bool,
>>> timer_id: T,
>>> handler: fn(&dyn TimerHandle),
>>> ) -> Result<Timer<T>, TimerError>
>>>
>>> I didn't know what an `UBaseType_t` is, and while "autoreload"
>>> sounded pretty intuitive, I wasn't sure about the semantics, so
>>> I looked it up (the example comes from `FreeRTOS`). In this
>>> context, it is a boolean saying whether the timer should repeat
>>> with the given periodicity, or whether it is a one-shot.
>>
>> FreeRTOS is written in C90 - a mistake, IMHO - and thus does not use
>> bool. Instead, it uses constants pdTRUE and pdFALSE of type
>> UBaseType_t. UBaseType_t is a type that is dependent on the target -
>> usually it is either 16-bit or 32-bit. But of course it doesn't matter
>> what the underlying types are - you use the typedef names, and the
>> documented constants.
>
> Thanks for the context. Your point that the underlying type
> doesn't matter is salient: it's opaque to the programmer, but
> 99% of the time the programmer doesn't need to worry about the
> details.
Yes.
>
>>> The timer_id is opaque to the timer, and it looks like it's used
>>> to facilitating the handler accessing timer-specific data. In
>>> C, passing it as a `void *` is used as a way to get a poor-man's
>>> overloading. But Rust has generics, I just made it generic over
>>> some type T.
>>
>> FreeRTOS uses "void *" to mean "pointer to internal structure that you
>> shouldn't be messing with". It uses this far too often, and is, IMHO, a
>> poor design choice. (I also dislike the silly Hungarian naming.) I
>> would much preferred if there had been :
>>
>> struct Internal_Timer_Struct;
>> typedef struct Internal_Timer_Struct * timer_id_t;
>>
>> and then the parameter "timer_id_t timer_id". So in a re-write, it
>> would not be a generic. (You might choose to use a generic for the
>> handler function type, so that handler callbacks could have parameters
>> of other types, but not for the timer id.)
>>
>> I am using these declarations from FreeRTOS (and LWIP) to demonstrate
>> the use of function typedefs in massively popular codebases, not to
>> claim FreeRTOS is a paradigm of C code design!
>
> Oh interesting; in this case, I had assumed it was treated as
> a callback-specific type so one could plumb extra context into
> the handler; the documentation I saw suggested it could be used
> by the handler to disambiguate several timers reusing the same
> handler function.
Actually, I have mixed these up, and you are correct - the void* id is
user-assigned, and you use it as you wish. There are other places in
FreeRTOS where pointer types get "erased" and reduced to void*
unnecessarily, but this was not one of them. (In my poor defence, the
FreeRTOS code I have doesn't use timers, and the bits it does use -
threads and queues, mainly - is abstracted to a C++ interface.)
>
>>> For example:
>>>
>>> [snip]
>>>
>>> Note this is decently complex behavior, but it's actually quite
>>> intuitive from the name and the type.
>>
>> You have got a very clear picture here, much of it from the names of the
>> types. For a Rust programmer, you give a good impression of experience
>> with C :-)
>
> I've been known to dabble.
>
>> The only mistake you made is that programmers working on systems using
>> FreeRTOS and the like, have a fear and loathing of "malloc", have never
>> heard of "abort()", and do not join our threads because they all run
>> until the power is switched off.
>
> Ha, fair; that was just a made-up example, based on other thread
> libraries I have used (in C). I didn't mean for it to be
> interpreted strictly in the context of FreeRTOS! :-D
>
>> [snip]
>>
>> Or just have :
>>
>> fnptr pc = first;
>> fnptr *pcptr = &pc;
>>
>> I don't see a need for "uintptr_t", except so that you have to have
>> casts like Bart had.
>
> Yes. But I wanted to remain faithful to his original, to show
> that one could write a more-or-less exact transliteration in C
> that was extremely similar to his chosen syntax.
>
>>> [Snip a bunch of Rust code; the point of which being that
>>> bart need not complain about lack of an alternative to C]
>
It was interesting to see the Rust code, but it made one thing clear to
me - Rust should be used for writing Rust code, and not for writing C
code in Rust syntax.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-21 18:43 +0000 |
| Message-ID | <11bb15a$mif$1@reader2.panix.com> |
| In reply to | #403421 |
In article <11balos$1042$2@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 21/10/2026 15:22, Dan Cross wrote: >[snip] >Actually, I have mixed these up, and you are correct - the void* id is >user-assigned, and you use it as you wish. There are other places in >FreeRTOS where pointer types get "erased" and reduced to void* >unnecessarily, but this was not one of them. (In my poor defence, the >FreeRTOS code I have doesn't use timers, and the bits it does use - >threads and queues, mainly - is abstracted to a C++ interface.) No problem! >It was interesting to see the Rust code, but it made one thing clear to >me - Rust should be used for writing Rust code, and not for writing C >code in Rust syntax. Yes. When we started working with Rust, most of us had a lot of experience in C, C++, etc, and we brought a lot of inherited bad habits to our Rust code. At one point, a colleague quipped that we were writing, "crust: C in Rust syntax!" We all thought that was a great play on words, and adopted it in self-deprecating terms. Some people get pretty insulted by it, but it was never intended that way. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-21 13:02 -0700 |
| Message-ID | <11bb5ou$8nfg$2@dont-email.me> |
| In reply to | #403412 |
On 10/21/2026 5:17 AM, David Brown wrote: [...] *_t intrudes into POSIX.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-22 08:57 +0200 |
| Message-ID | <11bcc4o$jt81$1@dont-email.me> |
| In reply to | #403434 |
On 21/10/2026 22:02, Chris M. Thomasson wrote: > On 10/21/2026 5:17 AM, David Brown wrote: > [...] > > *_t intrudes into POSIX. I don't program for POSIX, so I don't care. The same applies to most code that is used in connection with FreeRTOS, or LWIP. (Of course there will be some overlap - bits of code that are intended to run on a microcontroller but tested with code running native on a PC.) I don't know if the "_t" convention for type identifiers started with POSIX, but it has certainly far outgrown POSIX. And I think the smart folks behind POSIX know this, and will not assume that just because they pick a new type name ending in _t, it will not conflict with some user code. As C doesn't have namespaces, there is always a risk of conflicting names - you just have to try to avoid clashes in things you are likely to see.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-22 12:56 +0000 |
| Message-ID | <11bd15t$6dj$1@reader2.panix.com> |
| In reply to | #403441 |
In article <11bcc4o$jt81$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 21/10/2026 22:02, Chris M. Thomasson wrote: >> On 10/21/2026 5:17 AM, David Brown wrote: >> [...] >> >> *_t intrudes into POSIX. > >I don't program for POSIX, so I don't care. The same applies to most >code that is used in connection with FreeRTOS, or LWIP. (Of course >there will be some overlap - bits of code that are intended to run on a >microcontroller but tested with code running native on a PC.) > >I don't know if the "_t" convention for type identifiers started with >POSIX, but it has certainly far outgrown POSIX. And I think the smart >folks behind POSIX know this, and will not assume that just because they >pick a new type name ending in _t, it will not conflict with some user >code. As C doesn't have namespaces, there is always a risk of >conflicting names - you just have to try to avoid clashes in things you >are likely to see. It definitely predates POSIX. `typdef` appears to have come into the language with "Typesetter C", which first shipped in 7th Edition research Unix, and 7th Ed had types ending in `_t`; so 1979 or thereabouts. For instance, `daddr_t`, `time_t`, and `caddr_t` to represent disk block addresses, times, and generic addresses, respectively. Curiously, `size_t` isn't there yet, and appears to arrive in 3bsd (also 1979, but based on 32/V), where it is sized (it's just a typedef for `int`). `size_t` makes it back into Research Unix with the 8th Edition, based on 4BSD; probably 4.1. It is signed in 8th Ed, and is a typedef for `long`. My notes put it into AT&T Unix with System V Release 3, where it is unsigned. POSIX started in 1984, building on work done by /usr/group, and the first issue of POSIX was released in 1988. Anyway, the point is that the `_t` convention predates POSIX (and ANSI C) by about a decade. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-22 17:00 +0000 |
| Message-ID | <20261022095509.357@kylheku.com> |
| In reply to | #403443 |
On 2026-10-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote: > Anyway, the point is that the `_t` convention predates POSIX > (and ANSI C) by about a decade. Speaking of caddr_t, that one was spread outside of Unix. I remember caddr_t cropping up when I was working with Microsoft C on DOS in 1990. ANSI/ISO C and its void * were still new, and caddr_t was one of the conventions for a pointer-to-anything. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-10-22 16:54 +0000 |
| Message-ID | <20261022094427.210@kylheku.com> |
| In reply to | #403441 |
On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: > On 21/10/2026 22:02, Chris M. Thomasson wrote: >> On 10/21/2026 5:17 AM, David Brown wrote: >> [...] >> >> *_t intrudes into POSIX. > > I don't program for POSIX, so I don't care. The same applies to most > code that is used in connection with FreeRTOS, or LWIP. (Of course > there will be some overlap - bits of code that are intended to run on a > microcontroller but tested with code running native on a PC.) > > I don't know if the "_t" convention for type identifiers started with > POSIX, but it has certainly far outgrown POSIX. And I think the smart > folks behind POSIX know this, and will not assume that just because they > pick a new type name ending in _t, it will not conflict with some user > code. As C doesn't have namespaces, there is always a risk of > conflicting names - you just have to try to avoid clashes in things you > are likely to see. These namespace declarations are really just a "heads up". POSIX isn't saying, don't have an identifier ending in _t in a namespace shared by typedefs. Rather, it is saying that new typedefs appearing in POSIX will be in that namespace. Consider this argument: whenever POSIX or ISO C introduces a new public identifier, it's necessarily going to start with "a", or else if not, then with "b", or else with "c", ... or else with "z" or perhaps the underscore. That doesn't mean you stop using identifiers in programming. "nullptr" is now a keyword, previously a valid identifier not in any proclaimed reserved namespace. Progrems which used it have to be changed to work with the newer language. Avoiding proclaimed namespaces will not protect you from clashes; only from clashes that would occur in those namespaces. Some spaces like _t are too attractive to avoid, because they are tied to an important, popular convention that everyone understands, and the benefits outweigh the unrealized risk of a future clash. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-22 21:09 +0200 |
| Message-ID | <11bdn1j$14p5v$1@dont-email.me> |
| In reply to | #403450 |
On 22/10/2026 18:54, Kaz Kylheku wrote: > On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: >> On 21/10/2026 22:02, Chris M. Thomasson wrote: >>> On 10/21/2026 5:17 AM, David Brown wrote: >>> [...] >>> >>> *_t intrudes into POSIX. >> >> I don't program for POSIX, so I don't care. The same applies to most >> code that is used in connection with FreeRTOS, or LWIP. (Of course >> there will be some overlap - bits of code that are intended to run on a >> microcontroller but tested with code running native on a PC.) >> >> I don't know if the "_t" convention for type identifiers started with >> POSIX, but it has certainly far outgrown POSIX. And I think the smart >> folks behind POSIX know this, and will not assume that just because they >> pick a new type name ending in _t, it will not conflict with some user >> code. As C doesn't have namespaces, there is always a risk of >> conflicting names - you just have to try to avoid clashes in things you >> are likely to see. > > These namespace declarations are really just a "heads up". POSIX > isn't saying, don't have an identifier ending in _t in a namespace > shared by typedefs. Rather, it is saying that new typedefs appearing > in POSIX will be in that namespace. > > Consider this argument: whenever POSIX or ISO C introduces a new > public identifier, it's necessarily going to start with "a", or else if > not, then with "b", or else with "c", ... or else with "z" > or perhaps the underscore. > > That doesn't mean you stop using identifiers in programming. > > "nullptr" is now a keyword, previously a valid identifier not in > any proclaimed reserved namespace. Progrems which used it have > to be changed to work with the newer language. > > Avoiding proclaimed namespaces will not protect you from clashes; > only from clashes that would occur in those namespaces. > > Some spaces like _t are too attractive to avoid, because they are tied > to an important, popular convention that everyone understands, > and the benefits outweigh the unrealized risk of a future clash. > I agree entirely.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-22 12:46 -0700 |
| Message-ID | <11bdp73$15nor$1@dont-email.me> |
| In reply to | #403450 |
On 10/22/2026 9:54 AM, Kaz Kylheku wrote: > On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: >> On 21/10/2026 22:02, Chris M. Thomasson wrote: >>> On 10/21/2026 5:17 AM, David Brown wrote: >>> [...] >>> >>> *_t intrudes into POSIX. >> >> I don't program for POSIX, so I don't care. The same applies to most >> code that is used in connection with FreeRTOS, or LWIP. (Of course >> there will be some overlap - bits of code that are intended to run on a >> microcontroller but tested with code running native on a PC.) >> >> I don't know if the "_t" convention for type identifiers started with >> POSIX, but it has certainly far outgrown POSIX. And I think the smart >> folks behind POSIX know this, and will not assume that just because they >> pick a new type name ending in _t, it will not conflict with some user >> code. As C doesn't have namespaces, there is always a risk of >> conflicting names - you just have to try to avoid clashes in things you >> are likely to see. > > These namespace declarations are really just a "heads up". POSIX > isn't saying, don't have an identifier ending in _t in a namespace > shared by typedefs. Rather, it is saying that new typedefs appearing > in POSIX will be in that namespace. > > Consider this argument: whenever POSIX or ISO C introduces a new > public identifier, it's necessarily going to start with "a", or else if > not, then with "b", or else with "c", ... or else with "z" > or perhaps the underscore. > > That doesn't mean you stop using identifiers in programming. > > "nullptr" is now a keyword, previously a valid identifier not in > any proclaimed reserved namespace. Progrems which used it have > to be changed to work with the newer language. > > Avoiding proclaimed namespaces will not protect you from clashes; > only from clashes that would occur in those namespaces. > > Some spaces like _t are too attractive to avoid, because they are tied > to an important, popular convention that everyone understands, > and the benefits outweigh the unrealized risk of a future clash. > Touche. How about _this vs this_. I just use self and be done with it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-23 09:37 +0200 |
| Message-ID | <11bf2s9$1eo7q$2@dont-email.me> |
| In reply to | #403454 |
On 22/10/2026 21:46, Chris M. Thomasson wrote: > On 10/22/2026 9:54 AM, Kaz Kylheku wrote: >> On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: >>> On 21/10/2026 22:02, Chris M. Thomasson wrote: >>>> On 10/21/2026 5:17 AM, David Brown wrote: >>>> [...] >>>> >>>> *_t intrudes into POSIX. >>> >>> I don't program for POSIX, so I don't care. The same applies to most >>> code that is used in connection with FreeRTOS, or LWIP. (Of course >>> there will be some overlap - bits of code that are intended to run on a >>> microcontroller but tested with code running native on a PC.) >>> >> Avoiding proclaimed namespaces will not protect you from clashes; >> only from clashes that would occur in those namespaces. >> >> Some spaces like _t are too attractive to avoid, because they are tied >> to an important, popular convention that everyone understands, >> and the benefits outweigh the unrealized risk of a future clash. >> > > Touche. How about _this vs this_. I just use self and be done with it. Imagine, just for a moment, that the rest of us are not privy to the jumble of thoughts and ideas that jump around in your head. I don't have the context of what you are thinking about. So I have no idea what you mean by this. Instead of posting random out-of-context snippets of thought, either write posts that say what you are talking about, or don't bother. (And do /not/ imagine that posting reams of unconnected code is a useful alternative.) If you are trying to say something about avoiding C++ keywords when picking identifiers in C coding, say that. If you are trying to say something about naming conventions for C++ class members, feel free to talk about that too - in comp.lang.c++. If you are trying to say something else, say it. Or drop it, if you prefer.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-23 14:21 -0700 |
| Message-ID | <11bgj4c$265sc$2@dont-email.me> |
| In reply to | #403465 |
On 10/23/2026 12:37 AM, David Brown wrote: > On 22/10/2026 21:46, Chris M. Thomasson wrote: >> On 10/22/2026 9:54 AM, Kaz Kylheku wrote: >>> On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: >>>> On 21/10/2026 22:02, Chris M. Thomasson wrote: >>>>> On 10/21/2026 5:17 AM, David Brown wrote: >>>>> [...] >>>>> >>>>> *_t intrudes into POSIX. >>>> >>>> I don't program for POSIX, so I don't care. The same applies to most >>>> code that is used in connection with FreeRTOS, or LWIP. (Of course >>>> there will be some overlap - bits of code that are intended to run on a >>>> microcontroller but tested with code running native on a PC.) >>>> > >>> Avoiding proclaimed namespaces will not protect you from clashes; >>> only from clashes that would occur in those namespaces. >>> >>> Some spaces like _t are too attractive to avoid, because they are tied >>> to an important, popular convention that everyone understands, >>> and the benefits outweigh the unrealized risk of a future clash. >>> >> >> Touche. How about _this vs this_. I just use self and be done with it. > > Imagine, just for a moment, that the rest of us are not privy to the > jumble of thoughts and ideas that jump around in your head. I don't > have the context of what you are thinking about. So I have no idea what > you mean by this. > > Instead of posting random out-of-context snippets of thought, either > write posts that say what you are talking about, or don't bother. (And > do /not/ imagine that posting reams of unconnected code is a useful > alternative.) > > If you are trying to say something about avoiding C++ keywords when > picking identifiers in C coding, say that. If you are trying to say > something about naming conventions for C++ class members, feel free to > talk about that too - in comp.lang.c++. If you are trying to say > something else, say it. Or drop it, if you prefer. > Or, Well, _this vs this_ Are they both legal? I like self. void foo(struct foo* const self); vs void foo(struct foo* const _this); void foo(struct foo* const this); void foo(struct foo* const this_); ? For some reason I do not want to use this in C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-23 22:40 +0000 |
| Message-ID | <11bgno8$27pn2$1@dont-email.me> |
| In reply to | #403493 |
On Fri, 23 Oct 2026 14:21:15 -0700, Chris M. Thomasson wrote: > I like self. > > void foo(struct foo* const self); The trouble with a fixed name is, how do you refer to the instance of an outer class?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-10-23 18:33 -0700 |
| Message-ID | <11bh1u6$2av4s$1@dont-email.me> |
| In reply to | #403494 |
On 10/23/2026 3:40 PM, Lawrence D’Oliveiro wrote: > On Fri, 23 Oct 2026 14:21:15 -0700, Chris M. Thomasson wrote: > >> I like self. >> >> void foo(struct foo* const self); > > The trouble with a fixed name is, how do you refer to the instance of > an outer class? Well, self can be internal to the API logic. See, user code does not need to care how self is organized. It just needs to allocate n bytes aligned on a boundary and call into the API to init it. calling a deinit, or destroy whatever after its done. So the caller manages the main memory. After its done it can make the memory go out of scope or deallocate it, free or whatever. So, internal to the lib, self->foo is there.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-24 22:26 +0000 |
| Message-ID | <11bjbah$340l8$5@dont-email.me> |
| In reply to | #403495 |
On Fri, 23 Oct 2026 18:33:56 -0700, Chris M. Thomasson wrote: > On 10/23/2026 3:40 PM, Lawrence D’Oliveiro wrote: >> >> The trouble with a fixed name is, how do you refer to the instance >> of an outer class? > > Well, self can be internal to the API logic. If “self” refers to the current instance of the innermost class, how do you refer to an instance of an outer class?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-10-25 00:56 +0200 |
| Subject | Modelling self/this? (was Re: Taming The Switch-Statement) |
| Message-ID | <11bjd3b$1bqmq$1@dont-email.me> |
| In reply to | #403514 |
On 2026-10-25 00:26, Lawrence D’Oliveiro wrote: > On Fri, 23 Oct 2026 18:33:56 -0700, Chris M. Thomasson wrote: >> On 10/23/2026 3:40 PM, Lawrence D’Oliveiro wrote: >>> >>> The trouble with a fixed name is, how do you refer to the instance >>> of an outer class? >> >> Well, self can be internal to the API logic. > > If “self” refers to the current instance of the innermost class, how > do you refer to an instance of an outer class? I'm a bit confused about the intention of this sub-thread in CLC. Since you have already been (at least implicitly) referring to other languages (by mention of 'self' and 'this') I'd answer the question that (in principal) a language could qualify the access; for example, Simula has "THIS DerivedClass" or "THIS BaseClass", or whatever class in the actual class-path is visible. We could also access attributes that need an access qualification by the 'QUA' keyword to disambiguate names common in base and derived classes. Still curious about the "plan" (for "C") behind, why asking this. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-10-24 16:38 -0700 |
| Message-ID | <11bjfid$35feb$3@kst.eternal-september.org> |
| In reply to | #403514 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Fri, 23 Oct 2026 18:33:56 -0700, Chris M. Thomasson wrote:
>> On 10/23/2026 3:40 PM, Lawrence D’Oliveiro wrote:
>>> The trouble with a fixed name is, how do you refer to the instance
>>> of an outer class?
>>
>> Well, self can be internal to the API logic.
>
> If “self” refers to the current instance of the innermost class, how
> do you refer to an instance of an outer class?
What's a "class"?
There are ways to implement or simulate classes and inheritance in C.
Without knowing how that's being done, it's not very meaningful to ask
how to refer to an instance of an outer class.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-24 12:58 +0200 |
| Message-ID | <11bi2vp$2jjto$3@dont-email.me> |
| In reply to | #403493 |
On 23/10/2026 23:21, Chris M. Thomasson wrote: > On 10/23/2026 12:37 AM, David Brown wrote: >> On 22/10/2026 21:46, Chris M. Thomasson wrote: >>> On 10/22/2026 9:54 AM, Kaz Kylheku wrote: >>>> On 2026-10-22, David Brown <david.brown@hesbynett.no> wrote: >>>>> On 21/10/2026 22:02, Chris M. Thomasson wrote: >>>>>> On 10/21/2026 5:17 AM, David Brown wrote: >>>>>> [...] >>>>>> >>>>>> *_t intrudes into POSIX. >>>>> >>>>> I don't program for POSIX, so I don't care. The same applies to most >>>>> code that is used in connection with FreeRTOS, or LWIP. (Of course >>>>> there will be some overlap - bits of code that are intended to run >>>>> on a >>>>> microcontroller but tested with code running native on a PC.) >>>>> >> >>>> Avoiding proclaimed namespaces will not protect you from clashes; >>>> only from clashes that would occur in those namespaces. >>>> >>>> Some spaces like _t are too attractive to avoid, because they are tied >>>> to an important, popular convention that everyone understands, >>>> and the benefits outweigh the unrealized risk of a future clash. >>>> >>> >>> Touche. How about _this vs this_. I just use self and be done with it. >> >> Imagine, just for a moment, that the rest of us are not privy to the >> jumble of thoughts and ideas that jump around in your head. I don't >> have the context of what you are thinking about. So I have no idea >> what you mean by this. >> >> Instead of posting random out-of-context snippets of thought, either >> write posts that say what you are talking about, or don't bother. >> (And do /not/ imagine that posting reams of unconnected code is a >> useful alternative.) >> >> If you are trying to say something about avoiding C++ keywords when >> picking identifiers in C coding, say that. If you are trying to say >> something about naming conventions for C++ class members, feel free to >> talk about that too - in comp.lang.c++. If you are trying to say >> something else, say it. Or drop it, if you prefer. >> > > Or, Well, > > _this > > vs > > this_ > > Are they both legal? What do you mean, "legal" ? Identifiers in C can start with any letter (including most Unicode "letters") or underscore, or any other implementation-defined characters. Subsequent characters can be any of these or a normal digit from the basic source character set. The only identifiers you may not use are ones that match keywords. There are various patterns that are "reserved", depending on header usage, but using them is still "legal". The main ones to avoid are identifiers starting with two underscores, or one underscore and a capital letter. > > I like self. > > void foo(struct foo* const self); > > vs > > void foo(struct foo* const _this); > void foo(struct foo* const this); > void foo(struct foo* const this_); > > ? For some reason I do not want to use this in C. > Use whichever you like. I would personally avoid using an identifier in C that matches a keyword (or "contextual keyword") in C++, to make it easier to re-use the same code in C++. But you don't have to do the same.
[toc] | [prev] | [next] | [standalone]
Page 20 of 27 — ← Prev page 1 … 18 19 [20] 21 22 … 27 Next page →
Back to top | Article view | comp.lang.c
csiph-web