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 1 of 25 [1] 2 3 … 25 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-06 15:45 +0200 |
| Subject | Official list of top C annoyances |
| Message-ID | <117jqq0$2dd4g$1@dont-email.me> |
i think this list should be done maybe
but i would need to compose it
so this post is not yet a list but to open
a topic
two most top annoyances at the moment of my
memory is
I
need of predeclarations (this is that i need
to declare a symbol up its usage as it cant be seen down
in code)
ITS TERRIBLE ANNOYING AND USELESS
II
no adhoc enums (tags) type - i mean
such i dont need tod efine i just may use it
like
foo('red'); foo('quick');
where in foo
foo(ad_hoc_enum e)
{
if(e=='red) ....
}
no definitions just tags
some could say i could use structures
struct red {}
struct quick {}
its not bad idea but i need tod efine it and that is
a problem (besides type problems) i need adhoc
this is so usefull and needed its probably
SECOND TERRIBLE ANNOYANCE
III....
other candidates are
1) that i need to repeat type names foo(floay x, float y, float z)
instedad of foo(float x,y,x)
2) that i need end line with ";" (where newline sign should work
3) that "," operator dont work in many cases
4) & and | should also be used for logical imo
(i would need to rethink if t needs some changes in language and when it
ffalls) now
5) *p.s works bad
and yet few things
(i was writing on all this already but i hjust think official list
should be written)
[toc] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-06 15:52 +0200 |
| Message-ID | <117jr6c$2dgb5$1@dont-email.me> |
| In reply to | #401667 |
yet i forgot that == is annoying it should be = but the assigment should be something like IL rotated 90 degress right something more like ⊨ but more close to =
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-06 16:52 +0100 |
| Message-ID | <117k28d$2gadn$1@dont-email.me> |
| In reply to | #401667 |
On 06/09/2026 14:45, fir wrote:
> i think this list should be done maybe
> but i would need to compose it
>
> so this post is not yet a list but to open
> a topic
>
> two most top annoyances at the moment of my
> memory is
>
> I
>
> need of predeclarations (this is that i need
> to declare a symbol up its usage as it cant be seen down
> in code)
>
> ITS TERRIBLE ANNOYING AND USELESS
>
> II
>
> no adhoc enums (tags) type - i mean
> such i dont need tod efine i just may use it
>
> like
>
> foo('red'); foo('quick');
>
> where in foo
>
> foo(ad_hoc_enum e)
> {
> if(e=='red) ....
> }
>
>
> no definitions just tags
>
> some could say i could use structures
>
> struct red {}
> struct quick {}
>
> its not bad idea but i need tod efine it and that is
> a problem (besides type problems) i need adhoc
>
> this is so usefull and needed its probably
>
> SECOND TERRIBLE ANNOYANCE
>
> III....
>
> other candidates are
>
> 1) that i need to repeat type names foo(floay x, float y, float z)
> instedad of foo(float x,y,x)
>
> 2) that i need end line with ";" (where newline sign should work
>
> 3) that "," operator dont work in many cases
>
> 4) & and | should also be used for logical imo
> (i would need to rethink if t needs some changes in language and when it
> ffalls) now
>
> 5) *p.s works bad
>
>
> and yet few things
>
> (i was writing on all this already but i hjust think official list
> should be written)
Yeah, my own list had 100 annoyances.
But then, I also had my own language which fixed ALL OF THEM, and did a
lot more.
With C, I first tried creating a thin syntax wrapper, transpiled with a
300-line script into standard C, but this only dealt with a fraction of
them, and required code to be written in a certain way (to avoid needing
a full lexer).
The thing is nobody here can fix it for you.
So, if you don't want to do this work yourself:
* Use C even if it is annoying (it sounds like there are lots of things
you could do but aren't aware of them, so learn the language better).
* Switch languages. Most modern ones allow out of order functions (use a
function before it is defined; no declaration needed), plus have lots of
other features
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-06 21:41 +0200 |
| Message-ID | <117kfl3$2294f$1@dont-email.me> |
| In reply to | #401671 |
On 2026-09-06 17:52, bart wrote:
> On 06/09/2026 14:45, fir wrote:
>> i think this list should be done maybe
>> but i would need to compose it
>>
>> so this post is not yet a list but to open
>> a topic
>>
>> two most top annoyances at the moment of my
>> memory is
>>
>> I
>>
>> need of predeclarations (this is that i need
>> to declare a symbol up its usage as it cant be seen down
>> in code)
Are you saying you miss the option to do
x = 1.5;
/*
... 100 lines of code ...
*/
float x;
Or do you want to resolve *every* entity name by the linker
(without seeing the declaration at the place where it belongs)?
Or do you just not "like" typed languages? (Want more scripting?)
I suppose you are using the wrong language for your liking, and
complain in the wrong newsgroup.
>>
>> ITS TERRIBLE ANNOYING AND USELESS
Strange that you find a principle like that - one that you find
in most typed programming languages, I'd say! - "terrible".
(It may annoy _you_, but it's certainly not "useless".)
>>
>> II
>>
>> no adhoc enums (tags) type - i mean
>> such i dont need tod efine i just may use it
>>
>> [...]
>>
>> SECOND TERRIBLE ANNOYANCE
>>
>> III....
>>
>> other candidates are
>>
>> 1) that i need to repeat type names foo(floay x, float y, float z)
>> instedad of foo(float x,y,x)
Given the many typing errors you make I understand that you want
to have less to type.
I'm currently programming mostly in a language that supports your
preferred syntax rule, but I have no problem if a language doesn't.
>>
>> 2) that i need end line with ";" (where newline sign should work
You're obviously in the wrong newsgroup. It's typical that semantic
phrases are separated by delimiters (or, in "C", by terminators).
Again, I'm positive that is a common principle to define languages;
notable exceptions are many scripting languages.
You should think about what you buy, language design-wise, with the
decision to allow newlines instead, or to allow both.
Or just switch the language you are currently using and complaining
about.
>>
>> 3) that "," operator dont work in many cases
Not sure what you mean here.
Operators work on entities of their defined types and return a result
of some type.
Personally I have a critical view on considering the ',' as _operator_
in the first place (in "C"). Mostly it's used in programming languages
as a syntactical delimiter (that defines, for example, collaterality).
>>
>> 4) & and | should also be used for logical imo
>> (i would need to rethink if t needs some changes in language and when
>> it ffalls) now
But that's how it was initially defined and it's use is still possible
(if you consider subtle differences to '&&' and '||'). - But you won't
do anyone a favor if you use a language in your own - debatable! - way,
at least in cases where you'd cooperate with other people.
In your own program writing activities use the construct that you like.
>>
>> 5) *p.s works bad
It works as it's defined. And with the preferences as defined. (It's
also common in other languages to have struct-selectors bind strongly.)
What's "bad" about it? - If you intended to have a semantics of (*p).s
then just use p->s as it's been supposed.
(It may help to you learn the language you intend to use, before using
it.)
If you think "C" is badly defined, generally or concerning precedence
(with that or generally), just switch to a language that better suits
you.
>>
>>
>> and yet few things
>>
>> (i was writing on all this already but i hjust think official list
>> should be written)
Most things are either opinion and personal preferences (or just plain
ignorance). There's no use for a list; there'd be as many such lists as
there's people who are picky about some detail and think their opinion
is representative.
>
>
> Yeah, my own list had 100 annoyances.
>
> But then, I also had my own language which fixed ALL OF THEM, and did a
> lot more.
And it would be good (for all) if "fir" would just use your language,
and stop all the whining.
>
> With C, I first tried creating a thin syntax wrapper, transpiled with a
> 300-line script into standard C, but this only dealt with a fraction of
> them, and required code to be written in a certain way (to avoid needing
> a full lexer).
>
> The thing is nobody here can fix it for you.
>
> So, if you don't want to do this work yourself:
>
> * Use C even if it is annoying (it sounds like there are lots of things
> you could do but aren't aware of them, so learn the language better).
Check.
>
> * Switch languages. Most modern ones allow out of order functions (use a
> function before it is defined; no declaration needed), plus have lots of
> other features
Check.
Janis
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-07 09:37 +0200 |
| Message-ID | <117lpjb$31vr4$1@dont-email.me> |
| In reply to | #401673 |
Janis Papanagnou pisze: > On 2026-09-06 17:52, bart wrote: >> On 06/09/2026 14:45, fir wrote: >>> i think this list should be done maybe >>> but i would need to compose it >>> >>> so this post is not yet a list but to open >>> a topic >>> >>> two most top annoyances at the moment of my >>> memory is >>> >>> I >>> >>> need of predeclarations (this is that i need >>> to declare a symbol up its usage as it cant be seen down >>> in code) > > Are you saying you miss the option to do > > x = 1.5; > /* > ... 100 lines of code ... > */ > float x; > of course this is a common problem to me i got something like int quests_screen; in one file "screens.c" and i need an acces to it form another files but its not avaliable eventually c could dissalow that in a file but allow that visibility among files - but c dont understand the concept of files (which is rather bad) (maybe files just should be considered modules)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-07 11:35 +0100 |
| Message-ID | <117m41r$35rim$1@dont-email.me> |
| In reply to | #401676 |
On 07/09/2026 08:37, fir wrote: > Janis Papanagnou pisze: >> On 2026-09-06 17:52, bart wrote: >>> On 06/09/2026 14:45, fir wrote: >>>> i think this list should be done maybe >>>> but i would need to compose it >>>> >>>> so this post is not yet a list but to open >>>> a topic >>>> >>>> two most top annoyances at the moment of my >>>> memory is >>>> >>>> I >>>> >>>> need of predeclarations (this is that i need >>>> to declare a symbol up its usage as it cant be seen down >>>> in code) >> >> Are you saying you miss the option to do >> >> x = 1.5; >> /* >> ... 100 lines of code ... >> */ >> float x; >> > > of course this is a common problem to me i got > something like > > int quests_screen; > > in one file "screens.c" > > and i need an acces to it form another files > but its not avaliable > > eventually c could dissalow that in a file but allow that visibility > among files - but c dont understand the concept of files > (which is rather bad) (maybe files just should be considered modules) It sounds like you don't understand C. To solve this particular problem, create a header like this: screens.h: extern int quests_screen; // shared declaration In screens.c: #include "screens.h" int quests_screen; // definition (you can initialise here) In all files you want to use this from, add this line: #include "screens.h" That's how it has to work in C. Of course with proper modules, it's simpler: In screens.m (my language): global int quests_screen In lead module of application: module screens Now 'screens_quest' is available in all modules, even without a qualifier. And you don't even need to submit 'screens.m' to the compiler; it will find it. If you need such functionality, then perhaps do as David Brown suggested, just switch to C++, where your existing C code will still largely work. But I doubt whether C++'s newly acquired module scheme is quite as sweet as mine (however my language uses whole-program compilation; it works differently).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-07 13:15 +0200 |
| Message-ID | <117m6ca$35hat$1@dont-email.me> |
| In reply to | #401678 |
On 07/09/2026 12:35, bart wrote:
> On 07/09/2026 08:37, fir wrote:
>> Janis Papanagnou pisze:
>>> On 2026-09-06 17:52, bart wrote:
>>>> On 06/09/2026 14:45, fir wrote:
>>>>> i think this list should be done maybe
>>>>> but i would need to compose it
>>>>>
>>>>> so this post is not yet a list but to open
>>>>> a topic
>>>>>
>>>>> two most top annoyances at the moment of my
>>>>> memory is
>>>>>
>>>>> I
>>>>>
>>>>> need of predeclarations (this is that i need
>>>>> to declare a symbol up its usage as it cant be seen down
>>>>> in code)
>>>
>>> Are you saying you miss the option to do
>>>
>>> x = 1.5;
>>> /*
>>> ... 100 lines of code ...
>>> */
>>> float x;
>>>
>>
>> of course this is a common problem to me i got
>> something like
>>
>> int quests_screen;
>>
>> in one file "screens.c"
>>
>> and i need an acces to it form another files
>> but its not avaliable
>>
>> eventually c could dissalow that in a file but allow that visibility
>> among files - but c dont understand the concept of files
>> (which is rather bad) (maybe files just should be considered modules)
>
> It sounds like you don't understand C. To solve this particular problem,
> create a header like this:
>
> screens.h:
>
> extern int quests_screen; // shared declaration
>
> In screens.c:
>
> #include "screens.h"
> int quests_screen; // definition (you can initialise here)
>
> In all files you want to use this from, add this line:
>
> #include "screens.h"
>
Yes, that's the way to do it.
> That's how it has to work in C. Of course with proper modules, it's
> simpler:
>
> In screens.m (my language):
>
> global int quests_screen
>
> In lead module of application:
>
> module screens
>
> Now 'screens_quest' is available in all modules, even without a
> qualifier. And you don't even need to submit 'screens.m' to the
> compiler; it will find it.
While that is undoubtedly less typing, I'd question it being "proper
modules". I would say that a good modules system requires a higher
degree of explicit control and qualification. This kind of implicit
"find stuff automatically" and "import everything" is okay for small
programs up to perhaps a few dozen modules, and when everything is
written by one person (obviously that's fine for your personal
language), it does not scale well. A "proper" modules system can handle
multiple files or modules in a project with the same name (even C can
handle that), and multiple identifiers of the same name (C fails there).
>
> If you need such functionality, then perhaps do as David Brown
> suggested, just switch to C++, where your existing C code will still
> largely work.
Note that if you are using C++, it would be natural to use namespaces
and inline variables :
screens.h :
namespace screens {
inline int quest_screens = 123; // Optional initialisation
}
The choice of "inline" as the keyword here may seem odd - think of it as
being "for historical reasons". It lets you define, not just declare,
the variable in the header - but definitions are merged at link-time.
So you don't have to have a separate "int quest_screens = 123;" in a
.cpp file. (If the OP actually has any interest in moving to C++, the
discussion should be moved to or restarted in c.l.c++.)
There's a lot of features and complexity in C++ that many people
dislike, for good or bad reasons. But it is also possible to pick a
small subset of features and just use those - especially if you want to
work in a language that is basically C, but with a few added features.
>
> But I doubt whether C++'s newly acquired module scheme is quite as sweet
> as mine (however my language uses whole-program compilation; it works
> differently).
>
Presumably your language's modules fit exactly with what you think is
ideal, for your usage. For other people, I suspect C++'s scheme is a
better fit - though since it is made to cover a huge variety of
use-cases, and to fit with an existing language, few people will
consider it "perfect" for their own personal needs. That's always the
difference between a one-man language and mainstream languages.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-07 13:55 +0100 |
| Message-ID | <117mc7o$38uh5$1@dont-email.me> |
| In reply to | #401680 |
On 07/09/2026 12:15, David Brown wrote:
> On 07/09/2026 12:35, bart wrote:
>> On 07/09/2026 08:37, fir wrote:
>>> Janis Papanagnou pisze:
>>>> On 2026-09-06 17:52, bart wrote:
>>>>> On 06/09/2026 14:45, fir wrote:
>>>>>> i think this list should be done maybe
>>>>>> but i would need to compose it
>>>>>>
>>>>>> so this post is not yet a list but to open
>>>>>> a topic
>>>>>>
>>>>>> two most top annoyances at the moment of my
>>>>>> memory is
>>>>>>
>>>>>> I
>>>>>>
>>>>>> need of predeclarations (this is that i need
>>>>>> to declare a symbol up its usage as it cant be seen down
>>>>>> in code)
>>>>
>>>> Are you saying you miss the option to do
>>>>
>>>> x = 1.5;
>>>> /*
>>>> ... 100 lines of code ...
>>>> */
>>>> float x;
>>>>
>>>
>>> of course this is a common problem to me i got
>>> something like
>>>
>>> int quests_screen;
>>>
>>> in one file "screens.c"
>>>
>>> and i need an acces to it form another files
>>> but its not avaliable
>>>
>>> eventually c could dissalow that in a file but allow that visibility
>>> among files - but c dont understand the concept of files
>>> (which is rather bad) (maybe files just should be considered modules)
>>
>> It sounds like you don't understand C. To solve this particular
>> problem, create a header like this:
>>
>> screens.h:
>>
>> extern int quests_screen; // shared declaration
>>
>> In screens.c:
>>
>> #include "screens.h"
>> int quests_screen; // definition (you can initialise here)
>>
>> In all files you want to use this from, add this line:
>>
>> #include "screens.h"
>>
>
> Yes, that's the way to do it.
>
>> That's how it has to work in C. Of course with proper modules, it's
>> simpler:
>>
>> In screens.m (my language):
>>
>> global int quests_screen
>>
>> In lead module of application:
>>
>> module screens
>>
>> Now 'screens_quest' is available in all modules, even without a
>> qualifier. And you don't even need to submit 'screens.m' to the
>> compiler; it will find it.
>
> While that is undoubtedly less typing, I'd question it being "proper
> modules". I would say that a good modules system requires a higher
> degree of explicit control and qualification
A typical module scheme works like this:
* You have, say, a project of 100 modules
* Each module selectively exports some entities
* Each module selectively imports some subset of the other 99 modules
The result is that each module starts with some rag-tag collection of
'import' statements, each different from any other module, and needing a
lot of maintenance.
Eg. try changing the name of one module, or you decide to import a name
from an module that is not yet part of the import list; or some import
is no longer needed, but you can't easily know that.
I tried such a scheme and hated how messy it was and how much work was
involved.
With the current scheme, if the project was actually an unstructured
collection of 100 modules, then just one module (the one submitted to
the compiler) would start with 99 'module' statements. All the
information is in one place.
>This kind of implicit
> "find stuff automatically" and "import everything" is okay for small
> programs up to perhaps a few dozen modules
Actually mine is a 2-level scheme: a program is a collection of
subprograms, and each subprogram is a chummy set of modules which can
see each other's exported named entities. (That is, functions,
variables, named constants, types, records, enumerations, macros.)
So the lead module A for an application might look like this:
import sys # (usually implicit so not needed)
module b # files a.m b.m c.m d.m form main prog
module c
module d
import x # file x.m is lead module of a self-contained
# subprogram
Module X here may itself consist of several modules, where entities need
the 'export' attribute rather than 'global' to make them visible
outside; this part is hierarchical.
The main program does not need to know these details; just the set of
exported entities. If qualification is needed, an exported function F is
called as X.F(); it does not use the actual module name, which is opaque.
The whole thing is built like this:
mm a
No makefiles needed or a long list of files. The aims are to keep it
simple, uncluttered and effortless.
> A "proper" modules system can handle
> multiple files or modules in a project with the same name (even C can
> handle that)
Files with the same name are always troublesome. In my scheme, since
module and import names also form identifiers, those cannot clash within
the same scope.
In my example 'x' could also contain a module 'b' (it would need to be
in a different folder), but for other reasons, my scheme requires all
module names in an app to be unique.
(The language also other means to encapsulate entities, nested if
needed, and access them via namespaces; I don't consider that to be
'modules', but some languages do. 'Modules' can mean lots of things.)
>> But I doubt whether C++'s newly acquired module scheme is quite as
>> sweet as mine (however my language uses whole-program compilation; it
>> works differently).
>>
>
> Presumably your language's modules fit exactly with what you think is
> ideal, for your usage. For other people, I suspect C++'s scheme is a
> better fit - though since it is made to cover a huge variety of use-
> cases, and to fit with an existing language, few people will consider it
> "perfect" for their own personal needs.
Python is a mainstream language and its module scheme seems simple
enough (if not quite as simple as mine!).
That's always the difference
> between a one-man language and mainstream languages.
I'd be interested in what the C++ would look like for my example above;
let's say the main program uses modules A B C D, and the library uses X Y Z.
So, how that project info is imparted. And if Y exports a function F,
how that is declared, and how it might be called from A for example.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-07 15:24 +0200 |
| Message-ID | <117mduq$39jni$2@dont-email.me> |
| In reply to | #401682 |
bart pisze: > On 07/09/2026 12:15, David Brown wrote: >> On 07/09/2026 12:35, bart wrote: >>> On 07/09/2026 08:37, fir wrote: >>>> Janis Papanagnou pisze: >>>>> On 2026-09-06 17:52, bart wrote: >>>>>> On 06/09/2026 14:45, fir wrote: >>>>>>> i think this list should be done maybe >>>>>>> but i would need to compose it >>>>>>> >>>>>>> so this post is not yet a list but to open >>>>>>> a topic >>>>>>> >>>>>>> two most top annoyances at the moment of my >>>>>>> memory is >>>>>>> >>>>>>> I >>>>>>> >>>>>>> need of predeclarations (this is that i need >>>>>>> to declare a symbol up its usage as it cant be seen down >>>>>>> in code) >>>>> >>>>> Are you saying you miss the option to do >>>>> >>>>> x = 1.5; >>>>> /* >>>>> ... 100 lines of code ... >>>>> */ >>>>> float x; >>>>> >>>> >>>> of course this is a common problem to me i got >>>> something like >>>> >>>> int quests_screen; >>>> >>>> in one file "screens.c" >>>> >>>> and i need an acces to it form another files >>>> but its not avaliable >>>> >>>> eventually c could dissalow that in a file but allow that visibility >>>> among files - but c dont understand the concept of files >>>> (which is rather bad) (maybe files just should be considered modules) >>> >>> It sounds like you don't understand C. To solve this particular >>> problem, create a header like this: >>> >>> screens.h: >>> >>> extern int quests_screen; // shared declaration >>> >>> In screens.c: >>> >>> #include "screens.h" >>> int quests_screen; // definition (you can initialise >>> here) >>> >>> In all files you want to use this from, add this line: >>> >>> #include "screens.h" >>> >> >> Yes, that's the way to do it. >> >>> That's how it has to work in C. Of course with proper modules, it's >>> simpler: >>> >>> In screens.m (my language): >>> >>> global int quests_screen >>> >>> In lead module of application: >>> >>> module screens >>> >>> Now 'screens_quest' is available in all modules, even without a >>> qualifier. And you don't even need to submit 'screens.m' to the >>> compiler; it will find it. >> >> While that is undoubtedly less typing, I'd question it being "proper >> modules". I would say that a good modules system requires a higher >> degree of explicit control and qualification > > A typical module scheme works like this: > > * You have, say, a project of 100 modules typical project (i mean medium sized which is like 100k lines or less is not 100 modules its 100 files and its one module in a sense what c calls module and windows calls modules (dlls) thats kinda problem as files should not need headers so if my 100 files are for modeule which makes dll i will make .h file but if its exe i will make no one
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-07 15:33 +0200 |
| Message-ID | <117meeo$35hat$2@dont-email.me> |
| In reply to | #401682 |
On 07/09/2026 14:55, bart wrote: > On 07/09/2026 12:15, David Brown wrote: >> On 07/09/2026 12:35, bart wrote: >>> On 07/09/2026 08:37, fir wrote: >>>> Janis Papanagnou pisze: >>>>> On 2026-09-06 17:52, bart wrote: >>>>>> On 06/09/2026 14:45, fir wrote: >>>>>>> i think this list should be done maybe >>>>>>> but i would need to compose it >>>>>>> >>>>>>> so this post is not yet a list but to open >>>>>>> a topic >>>>>>> >>>>>>> two most top annoyances at the moment of my >>>>>>> memory is >>>>>>> >>>>>>> I >>>>>>> >>>>>>> need of predeclarations (this is that i need >>>>>>> to declare a symbol up its usage as it cant be seen down >>>>>>> in code) >>>>> >>>>> Are you saying you miss the option to do >>>>> >>>>> x = 1.5; >>>>> /* >>>>> ... 100 lines of code ... >>>>> */ >>>>> float x; >>>>> >>>> >>>> of course this is a common problem to me i got >>>> something like >>>> >>>> int quests_screen; >>>> >>>> in one file "screens.c" >>>> >>>> and i need an acces to it form another files >>>> but its not avaliable >>>> >>>> eventually c could dissalow that in a file but allow that visibility >>>> among files - but c dont understand the concept of files >>>> (which is rather bad) (maybe files just should be considered modules) >>> >>> It sounds like you don't understand C. To solve this particular >>> problem, create a header like this: >>> >>> screens.h: >>> >>> extern int quests_screen; // shared declaration >>> >>> In screens.c: >>> >>> #include "screens.h" >>> int quests_screen; // definition (you can initialise >>> here) >>> >>> In all files you want to use this from, add this line: >>> >>> #include "screens.h" >>> >> >> Yes, that's the way to do it. >> >>> That's how it has to work in C. Of course with proper modules, it's >>> simpler: >>> >>> In screens.m (my language): >>> >>> global int quests_screen >>> >>> In lead module of application: >>> >>> module screens >>> >>> Now 'screens_quest' is available in all modules, even without a >>> qualifier. And you don't even need to submit 'screens.m' to the >>> compiler; it will find it. >> >> While that is undoubtedly less typing, I'd question it being "proper >> modules". I would say that a good modules system requires a higher >> degree of explicit control and qualification > > A typical module scheme works like this: > > * You have, say, a project of 100 modules > * Each module selectively exports some entities > * Each module selectively imports some subset of the other 99 modules > OK so far. > The result is that each module starts with some rag-tag collection of > 'import' statements, each different from any other module, and needing a > lot of maintenance. No. People who write /structured/ code do not do "rag-tag". When a project is of a size where it is inconvenient to keep track of all the separate "import" (or "#include", or whatever) statements, you use a hierarchy. Instead of importing "dns", "udp", "http", etc., modules, you import "network". The common "network" module pulls in the sub-modules. You probably also organise things in directories and sub-directories, matching the module layout. It is /structured/. One of the things some developers were concerned about in C++ is that when you do this with #include's, compile times increase significantly - so people often tried to minimise the number of #include's. (For C, this is far less of a problem except perhaps for a few very bloated headers.) C++ modules reduce this effect to almost nothing. > > Eg. try changing the name of one module, or you decide to import a name > from an module that is not yet part of the import list; or some import > is no longer needed, but you can't easily know that. > As long as you have a reasonably organised structure, extra imports are rarely an issue (though it can be nice to remove them when tidying up). Renaming modules or files is never something done lightly in serious work, once the code is established - it means changes in your version control, and coordination across groups of developers. Changing the name in an "import" statement is a minor part of that, and it is not going to be forgotten. It is also something that can often be automated with refactoring tools in good IDEs (which are very helpful in navigating large projects). > I tried such a scheme and hated how messy it was and how much work was > involved. > > With the current scheme, if the project was actually an unstructured > collection of 100 modules, then just one module (the one submitted to > the compiler) would start with 99 'module' statements. All the > information is in one place. > The trick is, don't write code that is an unstructured collection of 100 modules. Structure and organise your code. > >This kind of implicit > > "find stuff automatically" and "import everything" is okay for small > > programs up to perhaps a few dozen modules > > Actually mine is a 2-level scheme: a program is a collection of > subprograms, and each subprogram is a chummy set of modules which can > see each other's exported named entities. (That is, functions, > variables, named constants, types, records, enumerations, macros.) > So your code is structured. Then you don't need - or want - a system that throws everything together in one pot. > So the lead module A for an application might look like this: > > import sys # (usually implicit so not needed) > module b # files a.m b.m c.m d.m form main prog > module c > module d > import x # file x.m is lead module of a self-contained > # subprogram > > Module X here may itself consist of several modules, where entities need > the 'export' attribute rather than 'global' to make them visible > outside; this part is hierarchical. > > The main program does not need to know these details; just the set of > exported entities. If qualification is needed, an exported function F is > called as X.F(); it does not use the actual module name, which is opaque. > > The whole thing is built like this: > > mm a > > No makefiles needed or a long list of files. The aims are to keep it > simple, uncluttered and effortless. It sounds far more like a way to keep things cluttered and disorganised. There is always a balance to be found between explicit and implicit, at all levels. Different people, and different projects, will look for different balance points. I can't say that your system appeals to me, as described here, but I accept that it suits you and the way you like to work. So I am not saying there is something wrong with the way you implement modules in your language, for your use in your projects - merely that it is not a scheme that would be considered ideal for other languages. > > > A "proper" modules system can handle > > multiple files or modules in a project with the same name (even C can > > handle that) > > Files with the same name are always troublesome. In my scheme, since > module and import names also form identifiers, those cannot clash within > the same scope. > > In my example 'x' could also contain a module 'b' (it would need to be > in a different folder), but for other reasons, my scheme requires all > module names in an app to be unique. > That is fine for small projects. And of course with a one-man language, it is not hard to avoid clashes, even when you have a hundred files. For bigger projects with multiple developers, and libraries and code from different places, it is unworkable. > (The language also other means to encapsulate entities, nested if > needed, and access them via namespaces; I don't consider that to be > 'modules', but some languages do. 'Modules' can mean lots of things.) > (Agreed - there is no fixed language-agnostic definition of "module".) >>> But I doubt whether C++'s newly acquired module scheme is quite as >>> sweet as mine (however my language uses whole-program compilation; it >>> works differently). >>> >> >> Presumably your language's modules fit exactly with what you think is >> ideal, for your usage. For other people, I suspect C++'s scheme is a >> better fit - though since it is made to cover a huge variety of use- >> cases, and to fit with an existing language, few people will consider >> it "perfect" for their own personal needs. > > Python is a mainstream language and its module scheme seems simple > enough (if not quite as simple as mine!). It's not bad, and works well with the language. "Simple" is not a good thing in and of itself. Nor is "complex". A "simple" solution can be great in small use-cases, but painful in bigger projects - and vice-versa. > > That's always the difference >> between a one-man language and mainstream languages. > I'd be interested in what the C++ would look like for my example above; > let's say the main program uses modules A B C D, and the library uses X > Y Z. > > So, how that project info is imparted. And if Y exports a function F, > how that is declared, and how it might be called from A for example. I've lost track of the hypothetical project organisation, and this is not really the right place for a tutorial on the details of C++ modules. However, I can point out one significant difference between C++ modules and, say, Python modules - in C++, the concept of "module" is independent of the concept of "namespace". That means that the fully qualified names used by the importer of a module depends on the namespaces used, not the module names. (Of course in a well-organised project, there will be clear correlations between module names, file names, and namespaces. But they don't have to be one-to-one.)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-07 16:34 +0100 |
| Message-ID | <117mlie$3co6q$1@dont-email.me> |
| In reply to | #401686 |
On 07/09/2026 14:33, David Brown wrote:
> On 07/09/2026 14:55, bart wrote:
>> A typical module scheme works like this:
>>
>> * You have, say, a project of 100 modules
>> * Each module selectively exports some entities
>> * Each module selectively imports some subset of the other 99 modules
>>
>
> OK so far.
>
>> The result is that each module starts with some rag-tag collection of
>> 'import' statements, each different from any other module, and needing
>> a lot of maintenance.
>
> No. People who write /structured/ code do not do "rag-tag".
>
> When a project is of a size where it is inconvenient to keep track of
> all the separate "import" (or "#include", or whatever) statements, you
> use a hierarchy. Instead of importing "dns", "udp", "http", etc.,
> modules, you import "network". The common "network" module pulls in the
> sub-modules. You probably also organise things in directories and sub-
> directories, matching the module layout. It is /structured/.
But it's a pattern I've seen a lot. In C also, as collections of
#includes; this example is from Lua, a project of only 35 modules, and
from one of its .c files:
#include "lprefix.h"
#include <float.h>
#include <limits.h>
#include <math.h>
#include <stdlib.h>
#include "lua.h"
#include "lcode.h"
#include "ldebug.h"
#include "ldo.h"
#include "lgc.h"
#include "llex.h"
#include "lmem.h"
#include "lobject.h"
#include "lopcodes.h"
#include "lparser.h"
#include "lstring.h"
#include "ltable.h"
#include "lvm.h"
Every file has a different set. In all, there are 28K lines of C code
among the .c files, and there are 466 #include lines. That is similar to
the maintenance nightmare where each file imports a particular set of
modules.
This is the project info for my C compiler project (the contents of
cc.m, the module submitted to the compiler):
module cc_cli
module cc_decls ! Global Data and Tables
module cc_tables
module cc_lex ! Lexing and Parsing
module cc_parse
module cc_genpcl ! Generate PCL (IL)
module cc_blockpcl
module cc_libpcl
module cc_lib ! Misc
module cc_support
module cc_headers ! Bundled (embedded) headers
module cc_show ! Diagnostics
$sourcepath "c:/mx/"
import pcl ! IL Backend
It shares a backend with the compiler for my own language; that one
lists 20+ other modules via that import statement.
So about 40 modules which are each specified exactly once. (Well, there
can be different versions of the above, each for a different configuration.)
This is it in action (the -r in each case will run the compiled program
in memory):
c:\cx>mm -r cc -r hello
Compiling cc.m to cc.(run)
Compiling hello.c to hello.(run)
Hello, World!
>> With the current scheme, if the project was actually an unstructured
>> collection of 100 modules, then just one module (the one submitted to
>> the compiler) would start with 99 'module' statements. All the
>> information is in one place.
>>
>
> The trick is, don't write code that is an unstructured collection of 100
> modules. Structure and organise your code.
And the trick also is, don't try and force a hierarchical structure when
there isn't one. My previous module schemes were strictly hierarchical;
it didn't work.
>> Files with the same name are always troublesome. In my scheme, since
>> module and import names also form identifiers, those cannot clash
>> within the same scope.
>>
>> In my example 'x' could also contain a module 'b' (it would need to be
>> in a different folder), but for other reasons, my scheme requires all
>> module names in an app to be unique.
>>
>
> That is fine for small projects. And of course with a one-man language,
> it is not hard to avoid clashes, even when you have a hundred files.
Lots of projects have 100 files or less. 100 files at 1Kloc/file average
is 100Kloc, or about a 1MB binary (for a language at C's level compiled
for x64).
In my Windows' System32 folder, some 90% of EXE and DLL files are under 1MB.
In my gcc installation, 97% of lib*.a files are under 1MB.
> For
> bigger projects with multiple developers, and libraries and code from
> different places, it is unworkable.
Projects that produce one giant, monolithic binary? If multiple binaries
are involved, then each is a separate project.
> I've lost track of the hypothetical project organisation, and this is
> not really the right place for a tutorial on the details of C++ modules.
> However, I can point out one significant difference between C++
> modules and, say, Python modules - in C++, the concept of "module" is
> independent of the concept of "namespace". That means that the fully
> qualified names used by the importer of a module depends on the
> namespaces used, not the module names. (Of course in a well-organised
> project, there will be clear correlations between module names, file
> names, and namespaces. But they don't have to be one-to-one.)
This is where I keep it simple: one file = one module = one namespace.
Although other namespaces can be created with records (I guess classes
in C++) and functions.
(The latter is not possible in C++ AFAIK. You can do this for example:
proc F =
const x = main.y + 100 # x/y are compile-time constants
end
proc main =
const y = 76
println F.x # 176
end
This could allow two functions to share a private static variable (not
locals or parameters).)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-09-08 00:50 +0200 |
| Message-ID | <117nf46$2294f$2@dont-email.me> |
| In reply to | #401689 |
On 2026-09-07 17:34, bart wrote: > On 07/09/2026 14:33, David Brown wrote: >> On 07/09/2026 14:55, bart wrote: > >>> A typical module scheme works like this: >>> >>> * You have, say, a project of 100 modules >>> * Each module selectively exports some entities >>> * Each module selectively imports some subset of the other 99 modules >> >> OK so far. >> >>> The result is that each module starts with some rag-tag collection of >>> 'import' statements, each different from any other module, and >>> needing a lot of maintenance. >> >> No. People who write /structured/ code do not do "rag-tag". >> >> When a project is of a size where it is inconvenient to keep track of >> all the separate "import" (or "#include", or whatever) statements, you >> use a hierarchy. Instead of importing "dns", "udp", "http", etc., >> modules, you import "network". The common "network" module pulls in >> the sub-modules. You probably also organise things in directories and >> sub- directories, matching the module layout. It is /structured/. > > But it's a pattern I've seen a lot. (Well, what we see in the wild can sometimes make one even sick.) The question is; how do we handle that (in our own projects, whether private or professional). > In C also, as collections of > #includes; this example is from Lua, a project of only 35 modules, and > from one of its .c files: > > #include "lprefix.h" > [ snip list of include directives ] It's even worse; given - as mentioned in another part of the thread - that #includes are costly we often find some means to avoid not only duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif) in the header files but also to prevent accessing the header file in the first place (by #ifndef LABEL, #include <label.h>, #endif). That makes such C/C++ code rather messy, IMO. (And makes one appreciate languages with an inherent good modularization method yet more.) > [...] > >>> Files with the same name are always troublesome. [...] Unless (if the used language doesn't support any inherent means) you take organizational precautions to alleviate that situation. > > Lots of projects have 100 files or less. [...] While I can confirm such a magnitude for my personal projects that's not the magnitude of files we worked with in our professional project contexts. Hint: large projects are themselves, usually hierarchically, structured (not only the code). (But I see below that you have your very own view of what you think is a "project" and see how you organize it. You'll know what suits you.) > >> For bigger projects with multiple developers, and libraries and code >> from different places, it is unworkable. > > Projects that produce one giant, monolithic binary? If multiple binaries > are involved, then each is a separate project. (You may defined that so if you feel that to be right for your cases.) Generally projects and binaries are not directly 1-to-1 related as you seem to believe. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-09-08 00:35 +0100 |
| Message-ID | <117nhom$3nf9e$1@dont-email.me> |
| In reply to | #401697 |
On 07/09/2026 23:50, Janis Papanagnou wrote: > On 2026-09-07 17:34, bart wrote: >> On 07/09/2026 14:33, David Brown wrote: >>> On 07/09/2026 14:55, bart wrote: >> >>>> A typical module scheme works like this: >>>> >>>> * You have, say, a project of 100 modules >>>> * Each module selectively exports some entities >>>> * Each module selectively imports some subset of the other 99 modules >>> >>> OK so far. >>> >>>> The result is that each module starts with some rag-tag collection >>>> of 'import' statements, each different from any other module, and >>>> needing a lot of maintenance. >>> >>> No. People who write /structured/ code do not do "rag-tag". >>> >>> When a project is of a size where it is inconvenient to keep track of >>> all the separate "import" (or "#include", or whatever) statements, >>> you use a hierarchy. Instead of importing "dns", "udp", "http", >>> etc., modules, you import "network". The common "network" module >>> pulls in the sub-modules. You probably also organise things in >>> directories and sub- directories, matching the module layout. It >>> is /structured/. >> >> But it's a pattern I've seen a lot. > > (Well, what we see in the wild can sometimes make one even sick.) > > The question is; how do we handle that (in our own projects, whether > private or professional). > >> In C also, as collections of #includes; this example is from Lua, a >> project of only 35 modules, and from one of its .c files: >> >> #include "lprefix.h" >> [ snip list of include directives ] > > It's even worse; given - as mentioned in another part of the thread - > that #includes are costly we often find some means to avoid not only > duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif) > in the header files but also to prevent accessing the header file in > the first place (by #ifndef LABEL, #include <label.h>, #endif). That > makes such C/C++ code rather messy, IMO. (And makes one appreciate > languages with an inherent good modularization method yet more.) The duplication is a problem. If 50 modules each includes the header files for a library such as SDL2, then a full build means a scanning the headers 50 times, which means 4000 header files (80 unique) and 2.5M lines of code (50K unique). I have suggested before that this can be mitigated, since such a header format is needlessly sprawling when used in a production environment (that is, by people who are /using/ the library and not developing it). This particular set of headers can be condensed from 80 headers/50Kloc to one header/3Kloc, where the target platform is known. There is still duplication but now it is scanning only 50 header files (1 unique) and 150Kloc (3K unique), so should be brisker. And those other mitigations can still be applied. >> [...] >> >>>> Files with the same name are always troublesome. [...] > > Unless (if the used language doesn't support any inherent means) you > take organizational precautions to alleviate that situation. It's messy anyway. Searching for include files in C is implementation defined. If the compiler is given a set of relative include paths to search in some order, then it will take the first 'file.h' it sees. If that has been deleted or renamed, then it may find a 'file.h' elsewhere, but the wrong one. You hope that it will generate some errors. Or maybe it you submitted the search paths in the wrong order. > >> >> Lots of projects have 100 files or less. [...] > > While I can confirm such a magnitude for my personal projects that's > not the magnitude of files we worked with in our professional project > contexts. Hint: large projects are themselves, usually hierarchically, > structured (not only the code). I work with three levels of a project: * A single EXE may import external DLL/shared libraries which in turn import others, so a hierarchy. In this case, each EXE/DLL file, which is a single binary, would represent a whole project for my language/compiler if it was my source code * Within a single EXE/DLL program, my 'subprograms' have their own hierarchy, usually simple * But within each subprogram, the module structure is flat, by design. (You will surely have seen projects that uses large numbers of tiny files, with perhaps one function in each. There is clearly little hierarchy there.) > that's > not the magnitude of files we worked with in our professional project > contexts. So, what are you saying: that a simple module scheme stops working at a certain scale? I'm saying that VERY MANY applications and libraries are at a scale where such a scheme would work. Including most open source C programs I've tried to build, and failed, because the build process was so complex and/or Linux-centric. > (But I see below that you have your very own view of what you think is > a "project" and see how you organize it. You'll know what suits you.) > >> >>> For bigger projects with multiple developers, and libraries and code >>> from different places, it is unworkable. >> >> Projects that produce one giant, monolithic binary? If multiple >> binaries are involved, then each is a separate project. > > (You may defined that so if you feel that to be right for your cases.) > > Generally projects and binaries are not directly 1-to-1 related as you > seem to believe. So what do you call that part of a project which does yield a single binary? It's that single binary, comprised from so many individual source files and that use some specific, existing shared libraries, which is what my whole-program language+compiler addresses. It is also what a big chunk of a C makefile is about, and such a tool would eliminate that part of it.
[toc] | [prev] | [next] | [standalone]
| From | Lane W <cactus_DAC@yahoo.com> |
|---|---|
| Date | 2026-09-07 17:43 -0600 |
| Message-ID | <117ni7f$3ngqe$2@dont-email.me> |
| In reply to | #401701 |
bart wrote: > On 07/09/2026 23:50, Janis Papanagnou wrote: >> On 2026-09-07 17:34, bart wrote: >>> On 07/09/2026 14:33, David Brown wrote: >>>> On 07/09/2026 14:55, bart wrote: >>> >>>>> A typical module scheme works like this: >>>>> >>>>> * You have, say, a project of 100 modules >>>>> * Each module selectively exports some entities >>>>> * Each module selectively imports some subset of the other 99 modules >>>> >>>> OK so far. >>>> >>>>> The result is that each module starts with some rag-tag collection >>>>> of 'import' statements, each different from any other module, and >>>>> needing a lot of maintenance. >>>> >>>> No. People who write /structured/ code do not do "rag-tag". >>>> >>>> When a project is of a size where it is inconvenient to keep track >>>> of all the separate "import" (or "#include", or whatever) >>>> statements, you use a hierarchy. Instead of importing "dns", "udp", >>>> "http", etc., modules, you import "network". The common "network" >>>> module pulls in the sub-modules. You probably also organise things >>>> in directories and sub- directories, matching the module layout. It >>>> is /structured/. >>> >>> But it's a pattern I've seen a lot. >> >> (Well, what we see in the wild can sometimes make one even sick.) >> >> The question is; how do we handle that (in our own projects, whether >> private or professional). >> >>> In C also, as collections of #includes; this example is from Lua, a >>> project of only 35 modules, and from one of its .c files: >>> >>> #include "lprefix.h" >>> [ snip list of include directives ] >> >> It's even worse; given - as mentioned in another part of the thread - >> that #includes are costly we often find some means to avoid not only >> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif) >> in the header files but also to prevent accessing the header file in >> the first place (by #ifndef LABEL, #include <label.h>, #endif). That >> makes such C/C++ code rather messy, IMO. (And makes one appreciate >> languages with an inherent good modularization method yet more.) > > The duplication is a problem. If 50 modules each includes the header > files for a library such as SDL2, then a full build means a scanning the > headers 50 times, which means 4000 header files (80 unique) and 2.5M > lines of code (50K unique). > > I have suggested before that this can be mitigated, since such a header > format is needlessly sprawling when used in a production environment > (that is, by people who are /using/ the library and not developing it). > > This particular set of headers can be condensed from 80 headers/50Kloc > to one header/3Kloc, where the target platform is known. > > There is still duplication but now it is scanning only 50 header files > (1 unique) and 150Kloc (3K unique), so should be brisker. And those > other mitigations can still be applied. > >>> [...] >>> >>>>> Files with the same name are always troublesome. [...] >> >> Unless (if the used language doesn't support any inherent means) you >> take organizational precautions to alleviate that situation. > > It's messy anyway. Searching for include files in C is implementation > defined. If the compiler is given a set of relative include paths to > search in some order, then it will take the first 'file.h' it sees. > > If that has been deleted or renamed, then it may find a 'file.h' > elsewhere, but the wrong one. You hope that it will generate some > errors. Or maybe it you submitted the search paths in the wrong order. > >> >>> >>> Lots of projects have 100 files or less. [...] >> >> While I can confirm such a magnitude for my personal projects that's >> not the magnitude of files we worked with in our professional project >> contexts. Hint: large projects are themselves, usually hierarchically, >> structured (not only the code). > > I work with three levels of a project: > > * A single EXE may import external DLL/shared libraries which in turn > import others, so a hierarchy. In this case, each EXE/DLL file, which is > a single binary, would represent a whole project for my > language/compiler if it was my source code > > * Within a single EXE/DLL program, my 'subprograms' have their own > hierarchy, usually simple > > * But within each subprogram, the module structure is flat, by design. > > (You will surely have seen projects that uses large numbers of tiny > files, with perhaps one function in each. There is clearly little > hierarchy there.) > > > that's > > not the magnitude of files we worked with in our professional project > > contexts. > > So, what are you saying: that a simple module scheme stops working at a > certain scale? I'm saying that VERY MANY applications and libraries are > at a scale where such a scheme would work. > > Including most open source C programs I've tried to build, and failed, > because the build process was so complex and/or Linux-centric. >> (But I see below that you have your very own view of what you think is >> a "project" and see how you organize it. You'll know what suits you.) >> >>> >>>> For bigger projects with multiple developers, and libraries and code >>>> from different places, it is unworkable. >>> >>> Projects that produce one giant, monolithic binary? If multiple >>> binaries are involved, then each is a separate project. >> >> (You may defined that so if you feel that to be right for your cases.) >> >> Generally projects and binaries are not directly 1-to-1 related as you >> seem to believe. > > So what do you call that part of a project which does yield a single > binary? > > It's that single binary, comprised from so many individual source files > and that use some specific, existing shared libraries, which is what my > whole-program language+compiler addresses. > > It is also what a big chunk of a C makefile is about, and such a tool > would eliminate that part of it. > One of the things I avoid in C# is a nasty makefile, and generally having to tool around in Unix. That is all taken care of by the C# compiler included in the suite I use to generate my programs.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-09-07 16:52 -0700 |
| Message-ID | <117nio1$3nm08$1@kst.eternal-september.org> |
| In reply to | #401702 |
Lane W <cactus_DAC@yahoo.com> writes:
[128 lines deleted]
> One of the things I avoid in C# is a nasty makefile, and generally
> having to tool around in Unix. That is all taken care of by the C#
> compiler included in the suite I use to generate my programs.
OK, I think we've established that you like C# better than C
(or C++).
This is comp.lang.c. Complaints about C are topical here, even
though some of the ones that introduced this thread are silly.
But if you want to discuss C#, please do so elsewhere.
--
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 | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-09-09 15:24 +0800 |
| Message-ID | <WQ7oS.388924$9H1.148976@fx01.ams4> |
| In reply to | #401703 |
On 08/09/2026 7:52 AM, Keith Thompson wrote: > Lane W <cactus_DAC@yahoo.com> writes: > [128 lines deleted] > >> One of the things I avoid in C# is a nasty makefile, and generally >> having to tool around in Unix. That is all taken care of by the C# >> compiler included in the suite I use to generate my programs. > > OK, I think we've established that you like C# better than C > (or C++). > > This is comp.lang.c. Complaints about C are topical here, even > though some of the ones that introduced this thread are silly. > But if you want to discuss C#, please do so elsewhere. > Oh, don't mind Keith. He likes to butt in on other people's discussions and behave like he's some owner of comp.lang.c. He's not. There isn't even a comp.lang.csharp group to direct people towards. I guess Keith will just have to start a discussion in news.groups.proposals about it. I've added microsoft.public.dotnet.csharp.general to this discussion, but I have no idea if Eternal September subscribes to it, which I be- lieve is what most techies use to access usenet. And the last on-topic post in microsoft.public.dotnet.csharp.general seems to have been six- teen years ago. That's a long time for nobody to get comp.lang.csharp running. So please feel free to complain in comp.lang.c -- and let the # be si- lent -- until someone gets irritated enough to make a proposal that sticks! Best wishes, and happy coding in C#! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-09 10:18 +0200 |
| Message-ID | <117r4oo$upm8$1@dont-email.me> |
| In reply to | #401759 |
Johann 'Myrkraverk' Oskarsson pisze: > On 08/09/2026 7:52 AM, Keith Thompson wrote: >> Lane W <cactus_DAC@yahoo.com> writes: >> [128 lines deleted] >> >>> One of the things I avoid in C# is a nasty makefile, and generally >>> having to tool around in Unix. That is all taken care of by the C# >>> compiler included in the suite I use to generate my programs. >> >> OK, I think we've established that you like C# better than C >> (or C++). >> >> This is comp.lang.c. Complaints about C are topical here, even >> though some of the ones that introduced this thread are silly. >> But if you want to discuss C#, please do so elsewhere. >> > > Oh, don't mind Keith. He likes to butt in on other people's discussions > and behave like he's some owner of comp.lang.c. He's not. There isn't > even a comp.lang.csharp group to direct people towards. I guess Keith > will just have to start a discussion in news.groups.proposals about it. > > I've added microsoft.public.dotnet.csharp.general to this discussion, > but I have no idea if Eternal September subscribes to it, which I be- > lieve is what most techies use to access usenet. And the last on-topic > post in microsoft.public.dotnet.csharp.general seems to have been six- > teen years ago. > > That's a long time for nobody to get comp.lang.csharp running. > > So please feel free to complain in comp.lang.c -- and let the # be si- > lent -- until someone gets irritated enough to make a proposal that > sticks! > > > Best wishes, and happy coding in C#! this is probably not god taking on this ...the offtopics imo depending on amount (yet quality)..if group has some focus it should be focus on c realted things with some offtopics possible not focus on c not realted offtopics with slight amount of c related... so i find some sense in what keith t says though i personally cant agree with his inner idea this group is only for discussing 1) c standards not 2) c ideas or 3) c programming
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-09-09 20:16 +0800 |
| Message-ID | <_6coS.258278$nBp.238039@fx02.ams4> |
| In reply to | #401764 |
On 09/09/2026 4:18 PM, fir wrote: > Johann 'Myrkraverk' Oskarsson pisze: >> On 08/09/2026 7:52 AM, Keith Thompson wrote: >>> Lane W <cactus_DAC@yahoo.com> writes: >>> [128 lines deleted] >>> >>>> One of the things I avoid in C# is a nasty makefile, and generally >>>> having to tool around in Unix. That is all taken care of by the C# >>>> compiler included in the suite I use to generate my programs. >>> >>> OK, I think we've established that you like C# better than C >>> (or C++). >>> >>> This is comp.lang.c. Complaints about C are topical here, even >>> though some of the ones that introduced this thread are silly. >>> But if you want to discuss C#, please do so elsewhere. >>> >> >> Oh, don't mind Keith. He likes to butt in on other people's discussions >> and behave like he's some owner of comp.lang.c. He's not. There isn't >> even a comp.lang.csharp group to direct people towards. I guess Keith >> will just have to start a discussion in news.groups.proposals about it. >> >> I've added microsoft.public.dotnet.csharp.general to this discussion, >> but I have no idea if Eternal September subscribes to it, which I be- >> lieve is what most techies use to access usenet. And the last on-topic >> post in microsoft.public.dotnet.csharp.general seems to have been six- >> teen years ago. >> >> That's a long time for nobody to get comp.lang.csharp running. >> >> So please feel free to complain in comp.lang.c -- and let the # be si- >> lent -- until someone gets irritated enough to make a proposal that >> sticks! >> >> >> Best wishes, and happy coding in C#! > > this is probably not god taking on this ...the offtopics imo depending > on amount (yet quality)..if group has some focus it should be focus on > c realted things with some offtopics possible not focus on c not realted > offtopics with slight amount of c related... > > so i find some sense in what keith t says though i personally cant agree > with his inner idea this group is only for discussing > > 1) c standards > > not > 2) c ideas > or > 3) c programming Yeah, I don't worry about Keith and trolls like him, and discuss what I want in comp.lang.c. Including meta discussions like this one, about what should and shouldn't be discussed in comp.lang.c. Plus, it's fairly clear none of the usual trolls code anything in C, as I demonstrated when I gave you some book recommendations. Best wishes, and happy C coding! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-09 14:31 +0200 |
| Message-ID | <117rjjd$14hqj$3@dont-email.me> |
| In reply to | #401784 |
Johann 'Myrkraverk' Oskarsson pisze: > On 09/09/2026 4:18 PM, fir wrote: >> Johann 'Myrkraverk' Oskarsson pisze: >>> On 08/09/2026 7:52 AM, Keith Thompson wrote: >>>> Lane W <cactus_DAC@yahoo.com> writes: >>>> [128 lines deleted] >>>> >>>>> One of the things I avoid in C# is a nasty makefile, and generally >>>>> having to tool around in Unix. That is all taken care of by the C# >>>>> compiler included in the suite I use to generate my programs. >>>> >>>> OK, I think we've established that you like C# better than C >>>> (or C++). >>>> >>>> This is comp.lang.c. Complaints about C are topical here, even >>>> though some of the ones that introduced this thread are silly. >>>> But if you want to discuss C#, please do so elsewhere. >>>> >>> >>> Oh, don't mind Keith. He likes to butt in on other people's discussions >>> and behave like he's some owner of comp.lang.c. He's not. There isn't >>> even a comp.lang.csharp group to direct people towards. I guess Keith >>> will just have to start a discussion in news.groups.proposals about it. >>> >>> I've added microsoft.public.dotnet.csharp.general to this discussion, >>> but I have no idea if Eternal September subscribes to it, which I be- >>> lieve is what most techies use to access usenet. And the last on-topic >>> post in microsoft.public.dotnet.csharp.general seems to have been six- >>> teen years ago. >>> >>> That's a long time for nobody to get comp.lang.csharp running. >>> >>> So please feel free to complain in comp.lang.c -- and let the # be si- >>> lent -- until someone gets irritated enough to make a proposal that >>> sticks! >>> >>> >>> Best wishes, and happy coding in C#! >> >> this is probably not god taking on this ...the offtopics imo depending >> on amount (yet quality)..if group has some focus it should be focus on >> c realted things with some offtopics possible not focus on c not realted >> offtopics with slight amount of c related... >> >> so i find some sense in what keith t says though i personally cant agree >> with his inner idea this group is only for discussing >> >> 1) c standards >> >> not >> 2) c ideas >> or >> 3) c programming > Yeah, I don't worry about Keith and trolls like him, and discuss what I > want in comp.lang.c. Including meta discussions like this one, about > what should and shouldn't be discussed in comp.lang.c. > > Plus, it's fairly clear none of the usual trolls code anything in C, as > I demonstrated when I gave you some book recommendations. > > > Best wishes, and happy C coding! keith probably used to call me a troll (oz i not stick to his own rigid rules) so i could eventuall call him back a troll but as i once said if i noticed it is better to value regular users of this group becouse if not hem the group culd not exist and i would have no place to talk at all so i dont call him a troll, becouse he is okay user overally i just disagree in some things
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-09-09 14:37 +0200 |
| Message-ID | <117rjun$14te0$1@dont-email.me> |
| In reply to | #401788 |
fir pisze: > Johann 'Myrkraverk' Oskarsson pisze: >> On 09/09/2026 4:18 PM, fir wrote: >>> Johann 'Myrkraverk' Oskarsson pisze: >>>> On 08/09/2026 7:52 AM, Keith Thompson wrote: >>>>> Lane W <cactus_DAC@yahoo.com> writes: >>>>> [128 lines deleted] >>>>> >>>>>> One of the things I avoid in C# is a nasty makefile, and generally >>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>> compiler included in the suite I use to generate my programs. >>>>> >>>>> OK, I think we've established that you like C# better than C >>>>> (or C++). >>>>> >>>>> This is comp.lang.c. Complaints about C are topical here, even >>>>> though some of the ones that introduced this thread are silly. >>>>> But if you want to discuss C#, please do so elsewhere. >>>>> >>>> >>>> Oh, don't mind Keith. He likes to butt in on other people's >>>> discussions >>>> and behave like he's some owner of comp.lang.c. He's not. There isn't >>>> even a comp.lang.csharp group to direct people towards. I guess Keith >>>> will just have to start a discussion in news.groups.proposals about it. >>>> >>>> I've added microsoft.public.dotnet.csharp.general to this discussion, >>>> but I have no idea if Eternal September subscribes to it, which I be- >>>> lieve is what most techies use to access usenet. And the last on-topic >>>> post in microsoft.public.dotnet.csharp.general seems to have been six- >>>> teen years ago. >>>> >>>> That's a long time for nobody to get comp.lang.csharp running. >>>> >>>> So please feel free to complain in comp.lang.c -- and let the # be si- >>>> lent -- until someone gets irritated enough to make a proposal that >>>> sticks! >>>> >>>> >>>> Best wishes, and happy coding in C#! >>> >>> this is probably not god taking on this ...the offtopics imo >>> depending on amount (yet quality)..if group has some focus it should >>> be focus on >>> c realted things with some offtopics possible not focus on c not realted >>> offtopics with slight amount of c related... >>> >>> so i find some sense in what keith t says though i personally cant agree >>> with his inner idea this group is only for discussing >>> >>> 1) c standards >>> >>> not >>> 2) c ideas >>> or >>> 3) c programming >> Yeah, I don't worry about Keith and trolls like him, and discuss what I >> want in comp.lang.c. Including meta discussions like this one, about >> what should and shouldn't be discussed in comp.lang.c. >> >> Plus, it's fairly clear none of the usual trolls code anything in C, as >> I demonstrated when I gave you some book recommendations. >> >> >> Best wishes, and happy C coding! > > keith probably used to call me a troll (oz i not stick to his own rigid > rules) > so i could eventuall call him back a troll but as i once said if i noticed > it is better to value regular users of this group becouse if not hem > the group culd not exist and i would have no place to talk at all > > so i dont call him a troll, becouse he is okay user overally i just > disagree in some things > besides he is partally right - he has a bit rigid definitions who troll is - but this is kinda complex matter becouse depending on definitions i may be a troll according to one, he may be atroll according to another and so on..and which definitions are good and for what reason is a complex thing - not sure if this is resolvable... generally i find whats good to improve some focus and knowledge here as godo and whats the oposite makin brainless spam is bad etc
[toc] | [prev] | [next] | [standalone]
Page 1 of 25 [1] 2 3 … 25 Next page →
Back to top | Article view | comp.lang.c
csiph-web