Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #401667 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-09-06 15:45 +0200 |
| Last post | 2026-10-05 04:32 +0200 |
| Articles | 20 on this page of 496 — 24 participants |
Back to article view | Back to comp.lang.c
Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-06 15:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-06 16:52 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-06 21:41 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 09:37 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 11:35 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 13:15 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 13:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:24 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 15:33 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-07 16:34 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 00:50 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 00:35 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 17:43 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-07 16:52 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 15:24 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 20:16 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:31 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 14:37 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-09 21:37 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:38 +0200
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-18 17:42 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 03:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 16:40 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 20:08 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:18 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 12:32 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:30 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 18:37 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 20:12 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 22:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 21:15 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:37 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:39 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 14:41 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:31 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:10 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 09:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:59 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:35 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:35 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 14:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:08 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 14:14 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:16 +0200
Re: Official list of top C annoyances Kaz Kylheku <046-301-5902@kylheku.com> - 2026-09-14 19:14 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 08:29 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 02:45 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:07 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:14 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 15:31 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:41 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 15:58 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:05 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:13 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 16:29 -0700
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:23 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 16:19 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:02 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:11 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 08:25 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 15:53 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:42 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 17:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 18:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 19:16 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:48 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 18:38 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:11 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 15:04 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 17:12 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 23:59 +0800
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:30 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:50 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:13 -0700
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:16 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:43 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 07:16 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-08 00:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 12:47 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-09 01:59 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 19:12 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-09 21:01 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 21:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 21:18 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:32 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:26 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-09 23:30 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 08:45 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 13:09 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:11 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 14:33 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 15:51 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:03 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 15:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:59 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 16:57 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:18 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 01:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:54 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:06 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 17:15 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 18:45 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:56 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:19 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 20:25 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 19:17 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-11 09:21 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 12:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:13 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-11 13:41 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 14:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:04 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:08 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:13 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-11 15:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:02 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 21:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 16:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 09:48 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:06 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-10 23:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 15:52 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:48 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 17:11 -0700
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-12 08:01 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 08:20 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 09:09 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 12:40 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 11:55 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 14:49 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:00 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 14:24 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:44 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:53 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 16:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 17:20 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 17:08 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 10:53 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:23 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 18:58 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:46 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-12 22:16 +0100
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 15:40 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:27 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 10:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 10:30 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 11:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 11:26 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:37 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:47 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:55 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:11 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-13 05:29 -0600
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 13:43 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-13 14:00 -0700
Re: Official list of top C annoyances Ike Naar <ike@sdf.org> - 2026-09-13 10:53 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 13:46 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 15:21 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 15:31 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 16:58 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-13 18:01 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 21:14 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:17 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:23 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 17:27 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-13 17:06 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 15:01 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 18:11 +0200
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-14 20:21 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:54 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-14 23:56 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 09:07 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 09:41 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 10:22 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 11:51 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-15 12:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 09:10 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:37 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:03 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:01 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 01:57 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 18:54 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-14 22:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 21:03 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 00:33 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-13 10:50 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-13 12:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 20:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:34 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 19:39 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-12 15:23 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-12 07:45 -0600
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-11 00:37 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-13 18:55 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 01:44 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-14 07:41 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:01 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 14:09 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 02:42 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 23:41 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 01:48 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-15 07:39 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 11:28 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-15 14:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-15 21:56 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 21:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 00:36 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 02:21 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 09:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 13:47 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-16 17:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 00:36 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 16:59 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 01:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-16 19:43 -0700
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 09:24 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 11:29 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 02:04 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 18:19 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 11:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:21 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:17 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:44 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:16 +0200
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-18 12:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:53 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:47 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:22 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:58 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 21:06 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:07 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:34 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:52 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:15 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 15:16 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 15:25 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:05 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 16:46 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:22 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:19 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:55 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:47 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 20:54 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:44 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 23:48 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 00:04 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 01:34 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 17:50 -0700
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 17:45 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:28 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-18 18:34 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 18:08 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:26 -0700
Re: Official list of top C annoyances gazelle@shell.xmission.com (Kenny McCormack) - 2026-09-18 20:39 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 13:10 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 13:20 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:30 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:38 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 21:00 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 10:17 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 11:29 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:52 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:06 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-20 15:58 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:55 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:41 +0300
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-22 01:53 +0800
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-22 11:28 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-22 11:34 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:00 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 14:22 +0000
Re: Official list of top C annoyances Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-09-22 15:04 +0000
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 16:38 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:28 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-10-06 01:29 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-19 22:01 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 20:28 +0000
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-18 05:42 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-18 08:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 10:23 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-18 15:24 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 16:31 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:29 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:14 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:42 -0700
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:39 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:24 +0100
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 00:19 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 02:06 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 20:20 -0700
Re: Official list of top C annoyances "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2026-09-19 03:26 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:56 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 11:08 +0100
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-19 13:25 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 10:45 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-19 15:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 16:17 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-19 09:45 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 13:11 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 14:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 17:24 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 11:06 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 20:07 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 12:26 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 22:57 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-19 17:27 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-19 20:09 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 12:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 12:42 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:08 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:22 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 14:54 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 23:24 +0200
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-21 15:06 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-21 16:36 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-21 17:45 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-21 20:54 +0300
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 15:02 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-22 21:02 +0300
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-20 15:58 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:19 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-20 23:49 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 16:17 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:49 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-20 15:18 -0700
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-20 15:41 +0000
Re: Official list of top C annoyances tTh <tth@none.invalid> - 2026-09-17 21:53 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 21:05 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 14:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 17:15 +0200
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 16:33 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 20:26 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:26 -0700
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-17 13:25 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 12:36 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 13:03 +0100
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-17 14:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-17 14:32 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:17 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-17 15:24 -0700
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-18 09:06 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 02:08 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:01 +0100
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-18 03:05 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-18 11:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 17:33 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:19 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:34 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:21 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 13:16 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 15:26 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-16 15:58 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 19:13 +0100
Re: Official list of top C annoyances scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:30 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 20:30 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-16 21:16 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-17 02:56 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:32 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-29 19:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-05 02:15 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:22 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 09:49 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-14 11:27 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:03 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-14 16:15 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:27 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-23 01:01 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-23 23:38 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 02:00 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 02:41 +0000
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-23 20:23 -0700
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-24 23:54 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 01:23 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-25 03:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:38 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:49 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:44 +0100
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 14:03 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-28 00:05 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 00:56 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 14:27 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 02:02 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-30 11:18 +0100
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 13:37 +0000
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-30 17:17 +0300
Re: Official list of top C annoyances cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 14:39 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-30 22:39 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-01 15:23 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 02:38 +0000
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-10-02 09:17 +0200
Re: Official list of top C annoyances Michael S <already5chosen@yahoo.com> - 2026-09-25 12:17 +0300
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-25 11:31 +0100
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-26 02:34 +0000
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-24 08:50 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-24 11:31 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-24 11:29 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-25 21:09 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-26 11:59 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-29 04:06 +0000
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 04:47 +0000
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-29 23:49 +0100
Re: Official list of top C annoyances antispam@fricas.org (Waldek Hebisch) - 2026-09-30 12:19 +0000
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:13 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-09 10:38 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:40 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 12:05 +0200
Re: Official list of top C annoyances Richard Harnden <richard.nospam@gmail.invalid> - 2026-09-09 15:23 +0100
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 23:07 +0200
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-09 15:52 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 01:00 +0200
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-18 10:17 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-18 09:29 +0200
Re: Official list of top C annoyances Jim Jackson <jj@franjam.org.uk> - 2026-09-19 13:46 +0000
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 09:15 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 06:16 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 14:38 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-10 18:36 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-10 10:11 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 00:48 +0200
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-29 03:18 +0000
Re: Official list of top C annoyances Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 12:58 -0700
Re: Official list of top C annoyances Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-22 23:21 +0000
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:47 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:20 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-07 09:53 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-07 23:59 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-07 16:04 -0600
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-07 04:06 -0700
Re: Official list of top C annoyances Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-07 20:05 +0800
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-07 15:32 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 12:59 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 13:09 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 14:15 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:35 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 14:49 +0200
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 16:05 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:18 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 09:45 -0600
Re: Official list of top C annoyances David Brown <david.brown@hesbynett.no> - 2026-09-08 20:41 +0200
Re: Official list of top C annoyances "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-08 12:39 -0700
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 15:55 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:02 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 17:39 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 18:47 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 18:19 -0700
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-08 19:24 -0600
Re: Official list of top C annoyances Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 19:26 -0700
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-09 03:25 +0200
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:13 +0200
Re: Official list of top C annoyances Lane W <cactus_DAC@yahoo.com> - 2026-09-09 07:38 -0600
Re: Official list of top C annoyances "Johann \"Myrkraverk\" Oskarsson" <johann@myrkraverk.invalid> - 2026-09-09 22:16 +0800
Re: Official list of top C annoyances Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 09:02 +0200
Re: Official list of top C annoyances Jan van den Broek <balglaas@dds.nl> - 2026-09-09 12:50 +0000
And then we reached C# (was Re: Official list of top C annoyances) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 08:51 +0200
Re: Official list of top C annoyances bart <bc@freeuk.com> - 2026-09-08 14:54 +0100
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-08 16:10 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-09-25 14:22 +0200
Re: Official list of top C annoyances fir <profesor.fir@gmail.com> - 2026-10-05 04:32 +0200
Page 21 of 25 — ← Prev page 1 … 19 20 [21] 22 23 … 25 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-14 16:15 +0200 |
| Message-ID | <1188vi8$1jevt$1@dont-email.me> |
| In reply to | #402056 |
fir pisze: > bart pisze: >> On 14/09/2026 08:49, fir wrote: >>> bart pisze: >>>> >>>> And it isn't really much to do with modules. C libraries have >>>> interfaces, usually as headers, but it doesn't have modules. >>> >>> >>> >>> out of contex as i not readed most of this branch but obviously C has >>> modules >>> >>> if you may compile some c files with no resolved 'linkage' to like .o >>> or .obj etc they are modules >> >> No. We might informally use 'modules' to mean individual source files >> or translation units. A program may comprise multiple translation >> units. C allows independent compilation of such units and there needs >> to be a linking process to combine them. >> >> This is not the same as a language supporting a proper module scheme. >> Otherwise even Assembly has modules! >> >> Without modules, building a program in C looks like this: >> >> tcc prog.c a.c b.c c.c d.c e.c ... >> >> With modules, it would be just: >> >> tcc prog.c >> >> Both produce prog.exe. This illustrates automatic discovery of the >> source files, but real modules would have other benefits too. >> >> > No, C has modules those compilation units are modules (it that make > binary modules that you can then link) > > ofc those modules are quite 'thin' or how to call it but for shure those > are modules.. what you cay with this example is specific functionality > related to modules but not all need to have it > > (also no need to enlight me on things i was talking quite clearly and > loudly many years ago (as far as i remember my first post oon this group > was on related things - i mean the problem that c cupports those modules > but dont support module names and it may simply make crash or clask of > symbols note i was not saying anything on 'proper module scheme', imo you could say thet support for modules in c is weak (as it is), but c allows you to ocomplile thise modules , design them, store them, link them etc, write web pages on them and so on im not sure in old times i wouldnt be able to make this language mistake and say "c has no modules", maybe i could and maybe i did it myself , maybe not (coz i rather kknew things like .o or .obj are modules so maybe not but im not sure).. today i thing its better to say 'c support for modules is weak ' than 'c has not a modules' but this is out of context coz if someone assumes he talks on some heavier module support in code c dont has it - but i was sayin im talking about this 'c has no modules' out of context..out of specific context it has weak support for modules (at leat implementations have it)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-22 23:27 +0000 |
| Message-ID | <118v2sv$19jvc$2@dont-email.me> |
| In reply to | #401829 |
On Wed, 9 Sep 2026 19:12:44 +0100, bart wrote:
> Some even specify individual names to be imported from a module.
> What a complete waste of time!
On the contrary, I think that’s great for managing complex code.
Python offers you a choice between, e.g.
from math import \
cos, sin
in which case you can happily use “cos” and “sin” unqualified in that
module, versus
import math
In which case you have to write “math.cos”, “math.sin” etc.
Either way, it is easy enough to search through the code to find out
where a name comes from; in both cases, it goes back to the import
statement that names the module.
Think of import statements as a cross-reference mechanism built into
the language. When initially reading the program, you will naturally
skip over any long list of imports at the start; but you will start
going back and referring to them as you come across particular names
and try to understand that they mean.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-23 01:01 +0100 |
| Message-ID | <118v4rt$1ad0u$1@dont-email.me> |
| In reply to | #402346 |
On 23/09/2026 00:27, Lawrence D’Oliveiro wrote: > On Wed, 9 Sep 2026 19:12:44 +0100, bart wrote: > >> Some even specify individual names to be imported from a module. >> What a complete waste of time! > > On the contrary, I think that’s great for managing complex code. > > Python offers you a choice between, e.g. > > from math import \ > cos, sin > > in which case you can happily use “cos” and “sin” unqualified in that > module, versus > > import math > > In which case you have to write “math.cos”, “math.sin” etc. > > Either way, it is easy enough to search through the code to find out > where a name comes from; in both cases, it goes back to the import > statement that names the module. > > Think of import statements as a cross-reference mechanism built into > the language. When initially reading the program, you will naturally > skip over any long list of imports at the start; but you will start > going back and referring to them as you come across particular names > and try to understand that they mean. When I turn on my Casio calculator then sin, cos etc all Just Work. Why do I need to faff around with import and from statements and even individually enable specific maths functions? How on earth does it help in managing code? Perhaps we should also be able to individually enable 'if', 'for' 'while' etc as needed! Your example uses functions which in my languages are built-ins anyway; they exist program-wide and cannot be shadowed. Python allows this: import math from math import sin math.pi = "Mmm, pie!" def sin(x): return "42" print (math.pi) print (sin(30/57.3)) While I'm not into languages where everything is immutable, this is ridiculous and dangerous. Let's take a library L that exports functions A-F, and a program comprising modules X, Y, Z that use some of those. You're saying it is fine to have: In X: from L import A,B,E,F In Y: from L import B,C,F In Z: from L import D,C,A The trouble is you start with an empty set of imports and need to keep augmenting these as your code evolves, or maybe remove some no longer used. So this set of imports is just one particular snapshot. In all it is just a massive pain for no gain that I can see. In my languages you just do: import L in ONE module, and all of them can now see A-F. (This may not be be a great fit for Python; AIUI, L may define 200 top-level names and **all** would be visible using 'import L' or 'from L import *'. This would not be an issue in my scheme, as the top-level names must be explicitly exported by L.)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-23 23:38 +0000 |
| Message-ID | <1191nt0$27o2u$1@dont-email.me> |
| In reply to | #402347 |
On Wed, 23 Sep 2026 01:01:01 +0100, bart wrote: > On 23/09/2026 00:27, Lawrence D’Oliveiro wrote: > >> Think of import statements as a cross-reference mechanism built >> into the language. When initially reading the program, you will >> naturally skip over any long list of imports at the start; but you >> will start going back and referring to them as you come across >> particular names and try to understand that they mean. > > When I turn on my Casio calculator then sin, cos etc all Just Work. > > Why do I need to faff around with import and from statements and > even individually enable specific maths functions? That’s OK for a relatively small, fixed set of functions, not so scalable when you have a potentially large, open-ended set of libraries that can be installed and imported from. My basic real-valued trig example may seem simple-minded to you, but remember, Python also offers complex maths <https://docs.python.org/3/library/cmath.html>. Note the functions have the same names. And that’s just a very basic case. There are more advanced ones I could mention.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-24 02:00 +0100 |
| Message-ID | <1191snv$299pm$1@dont-email.me> |
| In reply to | #402348 |
On 24/09/2026 00:38, Lawrence D’Oliveiro wrote: > On Wed, 23 Sep 2026 01:01:01 +0100, bart wrote: > >> On 23/09/2026 00:27, Lawrence D’Oliveiro wrote: >> >>> Think of import statements as a cross-reference mechanism built >>> into the language. When initially reading the program, you will >>> naturally skip over any long list of imports at the start; but you >>> will start going back and referring to them as you come across >>> particular names and try to understand that they mean. >> >> When I turn on my Casio calculator then sin, cos etc all Just Work. >> >> Why do I need to faff around with import and from statements and >> even individually enable specific maths functions? > > That’s OK for a relatively small, fixed set of functions, not so > scalable when you have a potentially large, open-ended set of > libraries that can be installed and imported from. I don't see the problem. My own projects share up up 2000 identifiers between modules. If using an external library such as SDL3, and I were to create a complete set of bindings, there would be 1200 functions exported, and nearly 3000 other identifiers, including named constants, enums, structs and types. If a small task involves using say several dozen of those, then I will just use them. All I want to write is: import sdl I don't find to collate the names and list them at the top; that would a waste of time. The next project will use other imports. They will not clash with anything else, because they all start with SDL_, and there namespaces. > My basic real-valued trig example may seem simple-minded to you, but > remember, Python also offers complex maths > <https://docs.python.org/3/library/cmath.html>. Note the functions > have the same names. > > And that’s just a very basic case. There are more advanced ones I > could mention. Python has some issues. Cmath using the same names as Math means you can't use 'from'. Also there is no filter: all sorts of local crap could be exported from Cmath that should be private.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-24 02:41 +0000 |
| Message-ID | <11922kv$29ujm$5@dont-email.me> |
| In reply to | #402349 |
On Thu, 24 Sep 2026 02:00:46 +0100, bart wrote: > On 24/09/2026 00:38, Lawrence D’Oliveiro wrote: >> >> On Wed, 23 Sep 2026 01:01:01 +0100, bart wrote: >> >>> On 23/09/2026 00:27, Lawrence D’Oliveiro wrote: >>> >>>> Think of import statements as a cross-reference mechanism built >>>> into the language. When initially reading the program, you will >>>> naturally skip over any long list of imports at the start; but >>>> you will start going back and referring to them as you come >>>> across particular names and try to understand that they mean. >>> >>> When I turn on my Casio calculator then sin, cos etc all Just >>> Work. >>> >>> Why do I need to faff around with import and from statements and >>> even individually enable specific maths functions? >> >> That’s OK for a relatively small, fixed set of functions, not so >> scalable when you have a potentially large, open-ended set of >> libraries that can be installed and imported from. > > I don't see the problem. > > My own projects share up up 2000 identifiers between modules. I suspect there’s more than that in the Python standard library alone. <https://docs.python.org/3/genindex-all.html> > I don't find to collate the names and list them at the top; that > would a waste of time. The next project will use other imports. > > They will not clash with anything else, because they all start with > SDL_ ... That’s a very crummy way of doing it, not to put too fine a point on it. >> My basic real-valued trig example may seem simple-minded to you, >> but remember, Python also offers complex maths >> <https://docs.python.org/3/library/cmath.html>. Note the functions >> have the same names. >> >> And that’s just a very basic case. There are more advanced ones I >> could mention. > > Python has some issues. Cmath using the same names as Math means you > can't use 'from'. Sure you can. Don’t know much about Python, do you? Find out more before trying to criticize. > Also there is no filter: all sorts of local crap could be exported > from Cmath that should be private. As Guido Van Rossum said, “We’re all consenting adults here”. If a name begins with an underscore, that’s a hint that it’s something internal to the module or class, and perhaps you shouldn’t be messing around with it. But if you really want to, and are willing to accept the consequences, you can. If you want a strict visiblity-controlling nanny language, stick to Java.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-23 20:23 -0700 |
| Message-ID | <1192540$2behs$1@kst.eternal-september.org> |
| In reply to | #402350 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Thu, 24 Sep 2026 02:00:46 +0100, bart wrote:
[...]
>> Python has some issues. Cmath using the same names as Math means you
>> can't use 'from'.
>
> Sure you can.
>
> Don’t know much about Python, do you? Find out more before trying to
> criticize.
But *please* find out somewhere else, not in comp.lang.c.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-24 11:27 +0100 |
| Message-ID | <1192tua$2ja5g$1@dont-email.me> |
| In reply to | #402350 |
On 24/09/2026 03:41, Lawrence D’Oliveiro wrote: > On Thu, 24 Sep 2026 02:00:46 +0100, bart wrote: > >> On 24/09/2026 00:38, Lawrence D’Oliveiro wrote: >>> >>> On Wed, 23 Sep 2026 01:01:01 +0100, bart wrote: >>> >>>> On 23/09/2026 00:27, Lawrence D’Oliveiro wrote: >>>> >>>>> Think of import statements as a cross-reference mechanism built >>>>> into the language. When initially reading the program, you will >>>>> naturally skip over any long list of imports at the start; but >>>>> you will start going back and referring to them as you come >>>>> across particular names and try to understand that they mean. >>>> >>>> When I turn on my Casio calculator then sin, cos etc all Just >>>> Work. >>>> >>>> Why do I need to faff around with import and from statements and >>>> even individually enable specific maths functions? >>> >>> That’s OK for a relatively small, fixed set of functions, not so >>> scalable when you have a potentially large, open-ended set of >>> libraries that can be installed and imported from. >> >> I don't see the problem. >> >> My own projects share up up 2000 identifiers between modules. > > I suspect there’s more than that in the Python standard library alone. You're missing my point: I can use those 2000 names by simpler listing their containing modules /at one place/ in the application. I don't need to list random subsets of those 2000 names at the top of each of the dozens of modules that comprise the project. That would be crazy. So it's a /better/ way of managing larger projects. > <https://docs.python.org/3/genindex-all.html> > >> I don't find to collate the names and list them at the top; that >> would a waste of time. The next project will use other imports. >> >> They will not clash with anything else, because they all start with >> SDL_ ... > > That’s a very crummy way of doing it, not to put too fine a point on it. Probably: the library needs to be usable from C so for that it works. And as I said, from languages like mine you can probably write sdl.SDL_init(), but that would be rather pointless. BTW the first Python example I found online started with this: from sdl2 import * >>> <https://docs.python.org/3/library/cmath.html>. Note the functions >>> have the same names. >>> >>> And that’s just a very basic case. There are more advanced ones I >>> could mention. >> >> Python has some issues. Cmath using the same names as Math means you >> can't use 'from'. Didn't you say 'Note the functions have the same names'? So here: from math import sin from cmath import sin print(sin(30/57)) That second sin replaces the first. > Don’t know much about Python, do you? Find out more before trying to > criticize. I've been following Python since the 1990s. >> Also there is no filter: all sorts of local crap could be exported >> from Cmath that should be private. > > As Guido Van Rossum said, “We’re all consenting adults here”. If a > name begins with an underscore, that’s a hint that it’s something > internal to the module or class, and perhaps you shouldn’t be messing > around with it. But if you really want to, and are willing to accept > the consequences, you can. Funny that I can't remember ever seeing such leading underscores. That sounds a bit like the 'static' rule C, which says that a function or variables shouldn't be exported. Lots of people never bother. In any case, if you do: from lib import * those bare _xxx names will be visible from this module. If _xxx names are defined here too, but someone makes a typo, they could inadvertently use lib's version. > If you want a strict visiblity-controlling nanny language, stick to > Java. Even C has better visibility control for top-level names.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-24 23:54 +0000 |
| Message-ID | <1194d6s$34hlg$5@dont-email.me> |
| In reply to | #402354 |
On Thu, 24 Sep 2026 11:27:21 +0100, bart wrote: > On 24/09/2026 03:41, Lawrence D’Oliveiro wrote: >> >> On Thu, 24 Sep 2026 02:00:46 +0100, bart wrote: >> >>> On 24/09/2026 00:38, Lawrence D’Oliveiro wrote: >>>> >>>> On Wed, 23 Sep 2026 01:01:01 +0100, bart wrote: >>>> >>>>> On 23/09/2026 00:27, Lawrence D’Oliveiro wrote: >>>>> >>>>>> Think of import statements as a cross-reference mechanism built >>>>>> into the language. When initially reading the program, you will >>>>>> naturally skip over any long list of imports at the start; but >>>>>> you will start going back and referring to them as you come >>>>>> across particular names and try to understand that they mean. >>>>> >>>>> When I turn on my Casio calculator then sin, cos etc all Just >>>>> Work. >>>>> >>>>> Why do I need to faff around with import and from statements and >>>>> even individually enable specific maths functions? >>>> >>>> That’s OK for a relatively small, fixed set of functions, not so >>>> scalable when you have a potentially large, open-ended set of >>>> libraries that can be installed and imported from. >>> >>> I don't see the problem. >>> >>> My own projects share up up 2000 identifiers between modules. >> >> I suspect there’s more than that in the Python standard library alone. >> >> <https://docs.python.org/3/genindex-all.html> > > You're missing my point: I can use those 2000 names by simpler > listing their containing modules /at one place/ in the application. > I don't need to list random subsets of those 2000 names at the top > of each of the dozens of modules that comprise the project. You’re missing *my* point: your approach doesn’t scale. I counted the number of lines on that page: there’s over 18,000 entries there. > BTW the first Python example I found online started with this: > > from sdl2 import * > I know. That kind of thing is all too commonly done. Trying to undo it is like dumping a can of worms on the ground, and then trying to pick them all up and put them back in the can. Not fun. >>>> <https://docs.python.org/3/library/cmath.html>. Note the >>>> functions have the same names. >>>> >>>> And that’s just a very basic case. There are more advanced ones I >>>> could mention. >>> >>> Python has some issues. Cmath using the same names as Math means >>> you can't use 'from'. >> >> Sure you can. > Didn't you say 'Note the functions have the same names'? So here: > > from math import sin > from cmath import sin >> >> Don’t know much about Python, do you? Find out more before trying >> to criticize. Start here: <https://docs.python.org/3/reference/simple_stmts.html#the-import-statement> >>> Also there is no filter: all sorts of local crap could be exported >>> from Cmath that should be private. >> >> As Guido Van Rossum said, “We’re all consenting adults here”. If a >> name begins with an underscore, that’s a hint that it’s something >> internal to the module or class, and perhaps you shouldn’t be >> messing around with it. But if you really want to, and are willing >> to accept the consequences, you can. > > Funny that I can't remember ever seeing such leading underscores. In other words, the visiblity convention is working, at least with newbies like you. ;)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-25 01:23 +0100 |
| Message-ID | <1194eu2$35hco$1@dont-email.me> |
| In reply to | #402368 |
On 25/09/2026 00:54, Lawrence D’Oliveiro wrote: > On Thu, 24 Sep 2026 11:27:21 +0100, bart wrote: > >> On 24/09/2026 03:41, Lawrence D’Oliveiro wrote: >>> <https://docs.python.org/3/genindex-all.html> >> >> You're missing my point: I can use those 2000 names by simpler >> listing their containing modules /at one place/ in the application. >> I don't need to list random subsets of those 2000 names at the top >> of each of the dozens of modules that comprise the project. > > You’re missing *my* point: your approach doesn’t scale. What doesn't scale: my application, the library, or both? What I'm saying is that it is this micromanagement that you're keen that becomes onerous when either app or library get larger, or both. I find it onerous at any time because I can't see the point of it and I don't want to do that extra housekeeping even at a small scale. > I counted the number of lines on that page: there’s over 18,000 > entries there. What is the relevance of that 18,000? How does it make anyone's life easier if you have to write and maintain hundreds of extra declarations in every module that uses some of those 18,000? You haven't explained it well. How about examples that use you approach and mine, that demonstrates the supposed 'problems' with the latter? >> BTW the first Python example I found online started with this: >> >> from sdl2 import * >> > > I know. That kind of thing is all too commonly done. Trying to undo it > is like dumping a can of worms on the ground, and then trying to pick > them all up and put them back in the can. Not fun. So, how would /you/ do it? For example, how would you write this simple program instead: from sdl2 import * SDL_init() > > Start here: > <https://docs.python.org/3/reference/simple_stmts.html#the-import-statement> Yes, Python's import facilities are a lot complex than mine.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-25 03:47 +0000 |
| Message-ID | <1194qsv$38hui$2@dont-email.me> |
| In reply to | #402370 |
On Fri, 25 Sep 2026 01:23:30 +0100, bart wrote:
> On 25/09/2026 00:54, Lawrence D’Oliveiro wrote:
>
>> I counted the number of lines on that page: there’s over 18,000
>> entries there.
>
> What is the relevance of that 18,000? How does it make anyone's life
> easier if you have to write and maintain hundreds of extra declarations
> in every module that uses some of those 18,000?
You don’t have to: that’s the point of being to explicitly control
what is imported.
>> On Thu, 24 Sep 2026 11:27:21 +0100, bart wrote:
>>
>>> BTW the first Python example I found online started with this:
>>>
>>> from sdl2 import *
>>
>> I know. That kind of thing is all too commonly done. Trying to undo it
>> is like dumping a can of worms on the ground, and then trying to pick
>> them all up and put them back in the can. Not fun.
>
> So, how would /you/ do it? For example, how would you write this simple
> program instead:
>
> from sdl2 import *
> SDL_init()
import sdl2
sdl2.init()
>> Start here:
>> <https://docs.python.org/3/reference/simple_stmts.html#the-import-statement>
>
> Yes, Python's import facilities are a lot complex than mine.
A lot more subtle than the understanding of them you have demonstrated
so far. Including dealing with the objection you tried to bring
against them.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-25 11:38 +0100 |
| Message-ID | <1195ius$3gdoc$1@dont-email.me> |
| In reply to | #402372 |
On 25/09/2026 04:47, Lawrence D’Oliveiro wrote:
> On Fri, 25 Sep 2026 01:23:30 +0100, bart wrote:
>
>> On 25/09/2026 00:54, Lawrence D’Oliveiro wrote:
>>
>>> I counted the number of lines on that page: there’s over 18,000
>>> entries there.
>>
>> What is the relevance of that 18,000? How does it make anyone's life
>> easier if you have to write and maintain hundreds of extra declarations
>> in every module that uses some of those 18,000?
>
> You don’t have to: that’s the point of being to explicitly control
> what is imported.
>
>>> On Thu, 24 Sep 2026 11:27:21 +0100, bart wrote:
>>>
>>>> BTW the first Python example I found online started with this:
>>>>
>>>> from sdl2 import *
>>>
>>> I know. That kind of thing is all too commonly done. Trying to undo it
>>> is like dumping a can of worms on the ground, and then trying to pick
>>> them all up and put them back in the can. Not fun.
>>
>> So, how would /you/ do it? For example, how would you write this simple
>> program instead:
>>
>> from sdl2 import *
>> SDL_init()
>
> import sdl2
>
> sdl2.init()
That wouldn't work unless you remove the SDL_ prefix from all the names
exported from 'sdl2'. But that will cause problems because the functions
exported from SDL2.DLL will still have 'SDL_'. You'd need to alias 1000
functions.
With sdl2 unchanged, you'd have to write this:
import sdl2
sdl2.SDL_init()
Which is going to add a lot of pointless clutter.
>
>>> Start here:
>>> <https://docs.python.org/3/reference/simple_stmts.html#the-import-statement>
>>
>> Yes, Python's import facilities are a lot complex than mine.
>
> A lot more subtle than the understanding of them you have demonstrated
> so far. Including dealing with the objection you tried to bring
> against them.
You're suggesting both complexity and subtle, unexpected behaviours are
good. In language design that is usually bad!
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-26 02:49 +0000 |
| Message-ID | <1197brr$4ikc$2@dont-email.me> |
| In reply to | #402385 |
On Fri, 25 Sep 2026 11:38:20 +0100, bart wrote:
> That wouldn't work unless you remove the SDL_ prefix from all the
> names exported from 'sdl2'.
Why would you need such a prefix anyway?
> But that will cause problems because the functions exported from
> SDL2.DLL will still have 'SDL_'. You'd need to alias 1000 functions.
This is Python. That’s easy to do.
True story: if you read the official OpenGL spec, all the names of
functions and constants are defined *without* “gl” or “GL_” prefixes
(respectively). Those prefixes are added in actual implementations
simply because, it seems, they are all done in C, which is a sad
language without support for namespaces.
Even more sadly, the C-language names carry over into wrappers for
higher-level languages that *do* support namespaces, like Python.
Which adds precisely the name clutter you describe. So I came up with
this simple routine to create my own library wrapper modules:
import types
import OpenGL
import OpenGL.GL
import OpenGL.GLU
def gen_gl() :
gl = types.ModuleType("gl", doc = "OpenGL routines")
GL = types.ModuleType("GL", doc = "OpenGL constants")
glu = types.ModuleType("glu", doc = "OpenGL utility routines")
GLU = types.ModuleType("GLU", doc = "OpenGL utility constants")
for prefix, src, dest in \
(
("gl", OpenGL.GL, gl),
("GL_", OpenGL.GL, GL),
("glu", OpenGL.GLU, glu),
("GLU_", OpenGL.GLU, GLU),
) \
:
for name in dir(src) :
if name.startswith(prefix) :
setattr(dest, name[len(prefix):], getattr(src, name))
#end if
#end for
#end for
return \
gl, GL, glu, GLU
#end gen_gl
gl, GL, glu, GLU = gen_gl()
del gen_gl # your work is done
Now I can write OpenGL calls like this (example from my “Shader” class
which wraps around an OpenGL shader):
def bind(self) :
"actually allocates GL resources and compiles the shader, if not already done so."
if self.id == None :
clear_error()
self.id = gl.CreateShader(self.type)
if self.id == 0 :
self.id = None
raise GLError(None, "creating shader")
#end if
gl.ShaderSource(self.id, self.source)
check_error("setting shader %d source" % self.id)
gl.CompileShader(self.id)
check_error("compiling shader %d source" % self.id)
if not gl.GetShaderiv(self.id, GL.COMPILE_STATUS) :
sys.stderr.write("Shader failed to compile source: %s\n" % self.source)
# debug
raise RuntimeError("Error compiling shader: " + gl.GetShaderInfoLog(self.id).decode())
#end if
#end if
#end bind
>> A lot more subtle than the understanding of them you have
>> demonstrated so far. Including dealing with the objection you tried
>> to bring against them.
>
> You're suggesting both complexity and subtle, unexpected behaviours
> are good.
What kind of “subtle, unexpected behaviours” do you get from the
import mechanism in Python? It’s actually designed to avoid that.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-26 11:44 +0100 |
| Message-ID | <11987n6$dd2f$1@dont-email.me> |
| In reply to | #402402 |
On 26/09/2026 03:49, Lawrence D’Oliveiro wrote:
> On Fri, 25 Sep 2026 11:38:20 +0100, bart wrote:
>
>> That wouldn't work unless you remove the SDL_ prefix from all the
>> names exported from 'sdl2'.
>
> Why would you need such a prefix anyway?
>
>> But that will cause problems because the functions exported from
>> SDL2.DLL will still have 'SDL_'. You'd need to alias 1000 functions.
>
> This is Python. That’s easy to do.
>
> True story: if you read the official OpenGL spec, all the names of
> functions and constants are defined *without* “gl” or “GL_” prefixes
> (respectively).
Link? Because here for example:
https://registry.khronos.org/OpenGL-Refpages/gl4/
the 'gl' is present. All exports from opengl.dll use 'gl' or 'wgl', and
from glu32.dll they have "glu". It would be confusing if several DLLs
all exported commonly named functions like "Start", "End", "Init", "Error".
In my own libraries, I also prefer an xx_ prefix even though I have a
module scheme, since, within the modules where those are defined, it
marks them as being part of the api and distinct from other local names.
It also helps avoid clashes: as it is I can have xx_abc and abc within
the same module. Or names like xx_end() since otherwise "end" is a
reserved word.
Those prefixes are added in actual implementations
> simply because, it seems, they are all done in C, which is a sad
> language without support for namespaces.
>
> Even more sadly, the C-language names carry over into wrappers for
> higher-level languages that *do* support namespaces, like Python.
> Which adds precisely the name clutter you describe.
No, the clutter I mentioned is having /both/ "sdl." and "SDL_".
Otherwise, you still need a prefix of "sdl." or "SDL_" either way. (In
my case-insensitive code, it would be "sdl." or "sdl_".)
So I came up with
> this simple routine to create my own library wrapper modules:
>
...
Would you really go to this much trouble in reality?
How much overhead are those attribute lookups going to add?
> Now I can write OpenGL calls like this (example from my “Shader” class
> which wraps around an OpenGL shader):> def bind(self) :
> "actually allocates GL resources and compiles the shader, if not already done so."
> if self.id == None :
> clear_error()
> self.id = gl.CreateShader(self.type)
> if self.id == 0 :
> self.id = None
> raise GLError(None, "creating shader")
> #end if
> gl.ShaderSource(self.id, self.source)
> check_error("setting shader %d source" % self.id)
> gl.CompileShader(self.id)
> check_error("compiling shader %d source" % self.id)
> if not gl.GetShaderiv(self.id, GL.COMPILE_STATUS) :
> sys.stderr.write("Shader failed to compile source: %s\n" % self.source)
> # debug
> raise RuntimeError("Error compiling shader: " + gl.GetShaderInfoLog(self.id).decode())
> #end if
> #end if
> #end bind
Yes, this is clearly better than:
> def bind(self) :
> "actually allocates GL resources and compiles the shader, if
not already done so."
> if self.id == None :
> clear_error()
> self.id = gl_CreateShader(self.type)
> if self.id == 0 :
> self.id = None
> raise GLError(None, "creating shader"
> #end if
> gl_ShaderSource(self.id, self.source)
> check_error("setting shader %d source" % self.id)
> gl_CompileShader(self.id)
> check_error("compiling shader %d source" % self.id)
> if not gl_GetShaderiv(self.id, GL_COMPILE_STATUS) :
> sys.stderr.write("Shader failed to compile source:
%s\n" % self.source)
> # debug
> raise RuntimeError("Error compiling shader: " +
gl_GetShaderInfoLog(self.id).decode())
> #end if
> #end if
> #end bind
(BTW what happened to GLError?)
> What kind of “subtle, unexpected behaviours” do you get from the
> import mechanism in Python? It’s actually designed to avoid that.
I gave an example:
from math import sin
from cmath import sin
print(sin(30/57))
One 'sin' silently replaces the other.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-26 14:03 +0100 |
| Message-ID | <1198fr1$gbi3$1@dont-email.me> |
| In reply to | #402404 |
On 26/09/2026 11:44, bart wrote: > On 26/09/2026 03:49, Lawrence D’Oliveiro wrote: > So I came up with >> this simple routine to create my own library wrapper modules: >> > ... > > Would you really go to this much trouble in reality? > > How much overhead are those attribute lookups going to add? I did a similar fix to my dynamic language. In this case it took 5 lines of code within the interpreter to add an SDL_ prefix to DLL function lookups when the library is called "sdl2". This is only done on demand, any only the first time any function is called. If the import block for the library is in a module called "sdl", then I can write SDL_init() etc as sdl.init() etc. Or as SDL.Init() since it is case-insensitive. No, I wouldn't normally bother with this either, but to show I can also apply hacks. Mine happen to be more efficient. What I /might/ bother doing is applying default parameter values and keyword arguments to selected API functions, since I have to generate my own bindings anyway. I do this for WinAPI. This is far more useful than worrying about a prefix.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-28 00:05 +0000 |
| Message-ID | <119cb0i$1sihs$2@dont-email.me> |
| In reply to | #402404 |
On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote: > Would you really go to this much trouble in reality? Yes. It wasn’t that much code, after all. I have done far more elaborate things. Like my wrapper for Cairo which added “Vector” as a type for passing 2D coordinates as a single value, where the underlying C API insisted on passing around separate x- and y-components. > How much overhead are those attribute lookups going to add? Fun fact: globals in Python also take name lookup overhead. > (BTW what happened to GLError?) That’s not part of the OpenGL API. That’s a name for my custom exception class. This allows the caller to easily catch OpenGL-specific exceptions, if they want, without confusing them for anything else. >> What kind of “subtle, unexpected behaviours” do you get from the >> import mechanism in Python? It’s actually designed to avoid that. > > I gave an example: > > from math import sin > from cmath import sin > > print(sin(30/57)) > > One 'sin' silently replaces the other. Nobody would do it that way, because you don’t need to. <https://docs.python.org/3/reference/simple_stmts.html#the-import-statement>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-29 00:56 +0000 |
| Message-ID | <119f2ce$2rkb9$1@dont-email.me> |
| In reply to | #402404 |
On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote: > On 26/09/2026 03:49, Lawrence D’Oliveiro wrote: >> >> True story: if you read the official OpenGL spec, all the names of >> functions and constants are defined *without* “gl” or “GL_” prefixes >> (respectively). > > Link? Because here for example: > > https://registry.khronos.org/OpenGL-Refpages/gl4/ > > the 'gl' is present. All exports from opengl.dll use 'gl' or 'wgl', and > from glu32.dll they have "glu". It would be confusing if several DLLs > all exported commonly named functions like "Start", "End", "Init", "Error". <https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf>
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-29 14:27 +0100 |
| Message-ID | <119geca$3aig7$1@dont-email.me> |
| In reply to | #402480 |
On 29/09/2026 01:56, Lawrence D’Oliveiro wrote:
> On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote:
>
>> On 26/09/2026 03:49, Lawrence D’Oliveiro wrote:
>>>
>>> True story: if you read the official OpenGL spec, all the names of
>>> functions and constants are defined *without* “gl” or “GL_” prefixes
>>> (respectively).
>>
>> Link? Because here for example:
>>
>> https://registry.khronos.org/OpenGL-Refpages/gl4/
>>
>> the 'gl' is present. All exports from opengl.dll use 'gl' or 'wgl', and
>> from glu32.dll they have "glu". It would be confusing if several DLLs
>> all exported commonly named functions like "Start", "End", "Init", "Error".
>
> <https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf>
Yes, I saw that. But all GL function names (as I assumed they were,
since they lacked the prefix) are scattered throughout the document.
There is no appendix listing all of them in one place and showing their
signatures.
'ReadPixels' for example occurs 35 times: once in the contents, once in
the index, plus 33 other instances.
One of those is part of its function signature, expressed as C syntax,
but without the GL prefix. This is 18.2.2 so you have to hunt for this info.
I looked for an explanation of why the prefixes are missing, but only
found this:
"Table 2.2: GL data types. GL types are not C types. Thus, for example,
GL type int is referred to as GLint outside this document, and is not
necessarily equivalent to the C type int"
This suggests that all other such names need to have GL outside, so why
not simply include it?
As it is, that function is shown like this:
void ReadPixels( int x, int y, sizei width, sizei height,
enum format, enum type, void *data );
So are those C ints or GLints? This is the actual signature from a C header:
void APIENTRY glReadPixels(GLint x,GLint y,GLsizei width,
GLsizei height,GLenum format,GLenum type,GLvoid *pixels);
I can see why the gl (as I can now see that it is) and GL are not shown:
they reduce readability. But this is how everyone will be using it.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-09-30 02:02 +0000 |
| Message-ID | <119hqj6$3r0er$4@dont-email.me> |
| In reply to | #402504 |
On Tue, 29 Sep 2026 14:27:37 +0100, bart wrote: > On 29/09/2026 01:56, Lawrence D’Oliveiro wrote: >> On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote: >> >>> On 26/09/2026 03:49, Lawrence D’Oliveiro wrote: >>>> >>>> True story: if you read the official OpenGL spec, all the names >>>> of functions and constants are defined *without* “gl” or “GL_” >>>> prefixes (respectively). >>> >>> Link? Because here for example: >>> >>> https://registry.khronos.org/OpenGL-Refpages/gl4/ >>> >>> the 'gl' is present. All exports from opengl.dll use 'gl' or >>> 'wgl', and from glu32.dll they have "glu". It would be confusing >>> if several DLLs all exported commonly named functions like >>> "Start", "End", "Init", "Error". >> >> <https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf> > > I can see why the gl (as I can now see that it is) and GL are not > shown: they reduce readability. But this is how everyone will be > using it. Only in languages that don’t support proper namespaces, as I pointed out.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-30 11:18 +0100 |
| Message-ID | <119inl6$4fd7$1@dont-email.me> |
| In reply to | #402533 |
On 30/09/2026 03:02, Lawrence D’Oliveiro wrote: > On Tue, 29 Sep 2026 14:27:37 +0100, bart wrote: > >> On 29/09/2026 01:56, Lawrence D’Oliveiro wrote: >>> On Sat, 26 Sep 2026 11:44:53 +0100, bart wrote: >>> >>>> On 26/09/2026 03:49, Lawrence D’Oliveiro wrote: >>>>> >>>>> True story: if you read the official OpenGL spec, all the names >>>>> of functions and constants are defined *without* “gl” or “GL_” >>>>> prefixes (respectively). >>>> >>>> Link? Because here for example: >>>> >>>> https://registry.khronos.org/OpenGL-Refpages/gl4/ >>>> >>>> the 'gl' is present. All exports from opengl.dll use 'gl' or >>>> 'wgl', and from glu32.dll they have "glu". It would be confusing >>>> if several DLLs all exported commonly named functions like >>>> "Start", "End", "Init", "Error". >>> >>> <https://www.khronos.org/registry/OpenGL/specs/gl/glspec46.core.pdf> >> >> I can see why the gl (as I can now see that it is) and GL are not >> shown: they reduce readability. But this is how everyone will be >> using it. > > Only in languages that don’t support proper namespaces, as I pointed > out. You snipped this quote: "Table 2.2: GL data types. GL types are not C types. Thus, for example, GL type int is referred to as GLint outside this document, and is not necessarily equivalent to the C type int" As I said, it is odd that they should use C syntax for the example, yet omit the prefixes that are necessary in C, which generates the confusion they refer to. I've looked at my system's OPENGL32.DLL file, and it exports 368 functions starting with "gl" or "wgl" or "Glmf" (So, three different namespaces? How are they distinguished within that document?) A set of language bindings could choose to consider those 'decorations', and strip the prefixes, so that you write: gl.Clear() instead of: glClear() Personally I don't see the advantage. It does make it possible to omit the qualifier so that you can write: Clear() But simple names like these risk clashes, also you lose the association with this specific library. So it comes down to the fact that, in practice, you end up using some sort of prefix anyway. Whether ".", "::", "_" or "" is used as a separator is a minor detail.
[toc] | [prev] | [next] | [standalone]
Page 21 of 25 — ← Prev page 1 … 19 20 [21] 22 23 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web