Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #379646 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2023-12-26 16:59 +0100 |
| Last post | 2024-01-08 22:20 -0800 |
| Articles | 20 on this page of 671 — 31 participants |
Back to article view | Back to comp.lang.c
Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-26 16:59 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-26 17:45 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-26 22:50 +0000
Re: Effect of CPP tags Spiros Bousbouras <spibou@gmail.com> - 2023-12-27 17:11 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 14:45 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-28 17:34 +0100
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 14:11 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 13:13 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:47 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-28 15:12 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 14:29 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 04:46 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 10:56 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 12:11 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 17:55 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:57 -0500
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-24 07:42 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-31 12:43 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:41 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-02-01 09:19 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:11 -0700
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-14 23:56 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-14 23:12 -0700
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 17:38 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:33 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:42 +0000
Re: Effect of CPP tags Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-12-28 18:04 -0500
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:11 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 16:04 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-28 21:22 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 15:52 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2023-12-29 17:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 11:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 22:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 14:40 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-12-31 12:43 -0500
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 12:57 +0100
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:32 -0800
usleep (Was: Effect of CPP tags) gazelle@shell.xmission.com (Kenny McCormack) - 2023-12-29 18:10 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-29 02:35 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 13:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-29 15:58 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:33 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:23 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-29 22:40 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 01:28 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-30 01:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:36 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:06 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:33 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 13:09 +0100
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-03 00:20 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 12:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 09:11 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2023-12-31 16:25 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:45 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:40 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 22:00 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:03 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 02:58 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:18 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:38 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 22:56 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 08:54 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 20:00 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:38 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 21:44 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 13:51 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 00:12 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:57 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 07:00 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:03 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:06 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 09:18 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-01 15:44 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 15:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 11:42 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:04 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-02 18:34 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:00 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 13:02 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-03 00:24 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:41 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 03:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 11:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 17:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:16 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-03 19:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:46 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 18:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 23:48 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 01:57 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 02:20 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 16:08 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-04 20:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 20:17 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 15:22 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-05 10:03 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:37 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:25 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-04 21:14 +0000
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-04 22:07 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 22:48 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-04 23:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 23:48 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-04 23:25 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 01:53 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-05 04:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 15:05 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 07:58 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-05 17:34 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 18:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 08:39 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 19:15 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 10:06 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:29 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 18:44 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 19:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 20:06 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 14:50 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:09 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 17:55 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-07 01:00 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:56 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:02 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 22:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-05 22:43 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 02:04 +0000
Re: Effect of CPP tags Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-05 23:02 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 01:45 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-05 18:17 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 10:09 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 10:27 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:23 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 13:40 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:09 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 16:40 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:58 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-07 15:48 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:34 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 13:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 20:50 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 01:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 08:30 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 11:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 15:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 17:46 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-09 19:56 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 21:33 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-09 21:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 22:22 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:37 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 12:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 14:17 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 14:31 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 16:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:57 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:55 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:49 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:26 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:19 -0800
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-11 00:30 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 01:14 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:25 -0800
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-11 17:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:31 +0000
Make (was: Re: Effect of CPP tags) vallor <vallor@cultnix.org> - 2024-01-15 21:01 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:29 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 17:46 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 17:58 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 19:16 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:30 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:27 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 14:22 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 17:37 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 23:27 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:05 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 00:40 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 16:49 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:04 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 19:17 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:26 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-10 11:22 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:54 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-10 02:57 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 05:28 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-10 06:28 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 09:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-09 23:40 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:10 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:10 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:55 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 11:42 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 14:59 -0800
Re: Effect of CPP tags vallor <vallor@cultnix.org> - 2024-01-11 14:58 +0000
A good place to discuss Makefiles? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-11 16:56 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-10 02:14 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:16 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-10 14:49 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 18:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 10:39 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 19:24 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 11:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 20:20 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-10 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 21:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-10 22:36 +0000
Re: Effect of CPP tags Paul <nospam@needed.invalid> - 2024-01-10 21:39 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 02:46 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 11:44 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 12:19 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 16:13 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 17:00 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 21:18 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-11 23:03 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 23:58 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:08 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 18:49 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 12:16 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-11 22:02 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 23:20 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-11 19:02 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 16:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 14:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:01 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 20:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 16:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 17:34 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:09 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 21:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 13:07 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:51 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 00:13 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:47 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 17:40 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 15:07 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-13 16:02 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:17 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 12:03 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 13:42 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 22:39 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-14 00:02 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 14:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-13 15:26 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 00:36 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-14 16:20 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:19 +0100
Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-15 15:46 +0100
Re: Makefile as an implementation instance of a transformation process (was Re: Effect of CPP tags) Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-15 15:41 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:54 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:17 +0000
Re: Effect of CPP tags Anthony Cuozzo <anthony@cuozzo.us> - 2024-01-14 13:44 -0500
Re: Effect of CPP tags Jim Jackson <jj@franjam.org.uk> - 2024-01-14 19:16 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 19:57 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:14 -0800
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 09:51 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 11:39 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:57 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:40 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:41 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:41 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:12 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 19:32 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:12 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:28 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 00:04 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:23 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:22 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:53 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:24 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:45 +0100
Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:01 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 11:44 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 12:21 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:10 +0100
Re: Switch fallthrough considered harmful? (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:35 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:48 +0100
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:42 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:56 +0000
Re: Effect of CPP tags Gabriel Rolland <gabrielrolland@gmail.com> - 2024-01-15 17:43 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 13:10 +0100
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-15 11:22 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:22 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 01:02 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 06:54 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-13 14:08 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 01:13 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:57 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 12:45 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-15 14:11 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 19:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 20:09 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 21:06 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 12:41 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:40 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:06 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 16:50 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 17:43 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 17:59 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-12 19:10 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 18:53 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:16 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:18 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:15 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:59 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 04:36 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:01 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:05 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:31 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 07:13 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 19:15 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-12 20:14 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-13 05:12 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-13 04:46 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:52 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 20:57 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 21:39 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:22 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 18:10 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 13:11 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 14:58 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 01:05 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 20:39 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-14 21:47 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 22:37 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 14:20 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:52 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 12:09 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-12 22:16 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:04 +0000
Re: Effect of CPP tags Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-12 23:30 +0000
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-13 00:16 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 11:16 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 18:47 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 19:42 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 22:18 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 23:48 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-17 16:23 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 00:25 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 00:47 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 04:30 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 10:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 19:40 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 20:21 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 11:07 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 11:17 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 12:41 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 13:18 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 15:42 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 15:03 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 18:12 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 18:28 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 18:43 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:48 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-19 17:32 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-19 17:05 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-19 19:50 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:18 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-19 14:14 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-19 16:18 +0000
Re: Effect of CPP tags dave_thompson_2@comcast.net - 2024-02-26 04:17 -0500
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-02-26 15:56 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 15:16 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 21:47 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-18 23:46 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-18 23:29 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:23 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-21 00:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 12:42 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-12 21:31 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:04 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-14 12:18 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 00:34 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 02:14 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:07 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 23:36 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 07:40 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:04 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 17:29 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:27 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-15 23:24 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 18:18 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:38 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 16:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:08 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 02:21 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:34 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 18:35 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-17 03:03 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 19:59 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:28 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 12:55 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:24 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 20:02 -0800
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:54 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 14:42 +0100
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:54 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:57 +0000
CPU's MAC instructions (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 06:25 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:52 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 14:15 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 14:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 15:44 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:35 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-15 18:55 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 19:19 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:31 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 01:21 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 11:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:06 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 17:04 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 13:43 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-17 13:00 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-18 13:00 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 13:28 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:55 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 22:02 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 15:55 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-16 18:39 +0000
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 00:11 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:11 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:42 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-18 21:44 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-15 12:28 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:39 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 16:23 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 17:30 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-15 21:25 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-15 20:41 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 15:08 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 16:02 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 19:03 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 18:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 23:00 +0100
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-16 22:10 +0000
Re: Effect of CPP tags Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-16 22:18 +0000
NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:11 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 14:17 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 16:33 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) David Brown <david.brown@hesbynett.no> - 2024-01-17 18:47 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) scott@slp53.sl.home (Scott Lurndal) - 2024-01-17 18:04 +0000
Re: NO vs. SE (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 19:15 +0100
Re: NO vs. SE (was Re: Effect of CPP tags) om@iki.fi (Otto J. Makela) - 2024-01-18 17:22 +0200
Re: NO vs. SE (was Re: Effect of CPP tags) Phil Carmody <pc+usenet@asdf.org> - 2024-03-24 14:24 +0200
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 12:26 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 16:29 +0100
Interpreter Dispatch in C (was: Effect of CPP Tags) bart <bc@freeuk.com> - 2024-01-16 19:21 +0000
Re: Interpreter Dispatch in C David Brown <david.brown@hesbynett.no> - 2024-01-16 23:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 15:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-16 18:46 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-16 22:42 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 14:25 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-17 14:51 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-17 19:07 +0100
Optimization and inline assembly (was Re: Effect of CPP tags) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-17 07:07 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 18:58 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-14 19:01 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-12 09:52 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-11 09:41 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-14 09:20 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 13:24 +0100
Re: Effect of CPP tags bart <bc@freeuk.com> - 2024-01-11 13:45 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-11 14:55 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-11 12:27 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:04 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-12 16:24 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:36 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 16:43 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:36 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 20:05 -0500
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 01:32 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:45 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-10 19:33 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:48 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-12 15:49 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 22:12 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 11:23 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-10 19:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 20:46 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-10 08:21 +0100
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 19:20 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-09 20:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 13:12 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:37 +0000
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-09 16:42 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:04 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 18:12 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-09 12:11 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 21:51 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 01:50 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:28 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-09 07:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-07 02:12 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:47 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:16 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 17:15 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 02:25 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-06 19:28 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 15:26 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 15:51 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 01:32 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 20:35 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 13:28 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:25 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 19:01 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:22 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 11:21 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 16:00 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-08 18:02 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:39 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:36 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 10:32 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-08 21:41 +0100
Re: Effect of CPP tags Ike Naar <ike@sdf.org> - 2024-01-08 08:53 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-08 09:59 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 12:53 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 14:11 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-06 15:28 +0100
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2024-01-06 09:56 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:57 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:58 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-06 23:45 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 00:21 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 00:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 01:26 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 02:14 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 12:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 19:29 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:41 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-07 23:27 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-06 15:43 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-07 03:32 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 11:37 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 14:41 -0800
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-07 22:54 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-07 16:06 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-05 15:54 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-05 16:23 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 09:55 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:15 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:29 +0100
Re: Effect of CPP tags tTh <tth@none.invalid> - 2024-01-06 05:33 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 17:41 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 21:32 +0000
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 15:13 +0100
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 13:42 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 12:46 +0100
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 12:37 +0000
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:51 -0500
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-04 18:21 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:43 -0800
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 17:39 -0500
Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-04 12:33 -0500
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-04 10:36 -0800
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-04 21:59 +0100
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-02 15:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 16:38 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:23 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:35 +0000
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-02 20:54 +0100
Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-01-03 20:28 +0100
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:45 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 23:08 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 18:16 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:05 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 21:45 +0000
Re: Effect of CPP tags Richard Damon <richard@damon-family.org> - 2023-12-29 11:58 -0500
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:44 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-29 10:54 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 20:19 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-12-30 06:51 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 16:16 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 23:21 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 19:14 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 01:34 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 02:18 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-30 23:46 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 15:26 +0000
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 17:26 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2023-12-31 19:23 +0000
Re: Effect of CPP tags Richard Damon <news.x.richarddamon@xoxy.net> - 2023-12-31 14:46 -0500
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 15:49 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-31 23:46 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 01:33 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 02:00 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 11:56 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 13:06 -0600
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 20:13 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2024-01-01 20:20 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 02:34 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:39 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:38 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 22:51 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 23:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-01 23:45 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:05 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 01:14 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 01:58 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 20:41 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-16 22:21 -0800
Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-02 06:23 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 06:47 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 12:24 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 19:04 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:11 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-02 20:43 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 23:55 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 02:08 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 02:40 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 12:10 +0000
Re: Effect of CPP tags Bart <bc@freeuk.cm> - 2024-01-03 13:03 +0000
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-03 19:14 +0000
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-03 15:33 +0000
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-03 08:37 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:54 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2024-01-02 20:05 +0000
Re: Effect of CPP tags Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-01 15:45 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 20:06 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 04:48 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:00 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-01 21:40 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:49 -0800
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-02 00:06 +0000
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:29 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 16:38 -0800
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 23:01 -0800
Re: Effect of CPP tags scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:37 +0000
Re: Effect of CPP tags BGB <cr88192@gmail.com> - 2023-12-31 16:59 -0600
Re: Effect of CPP tags Lawrence D'Oliveiro <ldo@nz.invalid> - 2023-12-30 20:12 +0000
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 16:07 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 16:36 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-31 18:31 -0800
Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-12-31 19:08 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-21 12:36 -0800
Re: Effect of CPP tags Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-01 05:56 +0100
Re: Effect of CPP tags "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:59 -0800
Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-08 22:20 -0800
Page 5 of 34 — ← Prev page 1 … 3 4 [5] 6 7 … 34 Next page →
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-01 15:54 +0000 |
| Message-ID | <umun7n$28l7q$1@dont-email.me> |
| In reply to | #379751 |
On 01/01/2024 14:44, David Brown wrote: > On 31/12/2023 22:44, Lawrence D'Oliveiro wrote: >> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote: >> >>> I realise that you (and possibly others) might find it useful for a tool >>> to replace typedef identifiers with their definitions, but it could only >>> be done for some cases, and is not as simple as macro substitution. >> >> String-based macros are nothing but trouble. > > What a strange thing to say. > > Macros based on textual substitution have their advantages and their > disadvantages. It is a reasonable generalisation to say you should > prefer alternatives when available, such as inline functions, const > objects, enum constants, typedefs, etc., rather than macro equivalents. > But there are plenty of situations where C's pre-processor macros are > extremely useful in writing good, clear and maintainable code. The cases where macros are used sensibly would be better replaced by apt language features (D does this for example as it is no preprocessor). But I tend to come across the ones where macros are overused or abused. Some people seem to delight in doing so. When working the Lua sources a few months ago, that makes heavy uses of macros defined in lower case which look just like functions calls. One complex expression that my compiler had trouble with, when expanded, resulted in a line hundreds of character long, and using 11 levels of nested parentheses, the most I've ever come across. I really doubt that the authors would have written code that convoluted if macros had not been available. >> Typedefs are scoped, string >> macros are not. > > True. Sometimes that is an advantage, sometimes a disadvantage. When it is an advantage? My systems language only acquired macros with parameters a year or two ago. They can only be used to expand to well-formed terms of expressions, and are used very sparingly. They have normal scoping, so can be shadowed or have distinct versions in different scopes and functions can define their own macros; they can be imported or exported just like functions and variables. The sorts of macros that C has seem stone age by comparison. And crude, in being able to define random bits of syntax, or synthesise tokens from multiple parts. Some people will obviously love that, but imagine trying to search for some token with a text editor, but it won't find it because it only exists after preprocessing. > Like any powerful tool, macros can be abused or misused, leading to > poorer results - but that does not mean they are "nothing but trouble". I wouldn't use the work 'powerful'; 'dangerous' and 'crazy' might be more apt. Imagine a CPP that could also map one letter another; more 'powerful', or just more 'crazy'?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-02 11:42 +0100 |
| Message-ID | <un0pb2$2kp7q$1@dont-email.me> |
| In reply to | #379753 |
On 01/01/2024 16:54, Bart wrote: > On 01/01/2024 14:44, David Brown wrote: >> On 31/12/2023 22:44, Lawrence D'Oliveiro wrote: >>> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote: >>> >>>> I realise that you (and possibly others) might find it useful for a >>>> tool >>>> to replace typedef identifiers with their definitions, but it could >>>> only >>>> be done for some cases, and is not as simple as macro substitution. >>> >>> String-based macros are nothing but trouble. >> >> What a strange thing to say. >> >> Macros based on textual substitution have their advantages and their >> disadvantages. It is a reasonable generalisation to say you should >> prefer alternatives when available, such as inline functions, const >> objects, enum constants, typedefs, etc., rather than macro >> equivalents. But there are plenty of situations where C's >> pre-processor macros are extremely useful in writing good, clear and >> maintainable code. > > > The cases where macros are used sensibly would be better replaced by apt > language features (D does this for example as it is no preprocessor). Except when they can't. Now, D (like C++) can certainly do some things without a preprocessor that need the preprocessor in C. Classic examples are generic functions, such as a type-adaptive "max" function. In C, you need to use a macro for this - in D or C++ you'd use a template. And some cases of conditional compilation in C can be replaced by "static if" in D or "if constexpr" in C++. And in general, I believe most people will agree that if you can use "core language" features rather than the preprocessor to achieve your purpose in a good, clear manner, then it is preferable to use the core language. However, there are things that you can't do - or can't do well - without a preprocessor. And you either live without these things, or you use a preprocessor. (And people do sometimes use a C preprocessor with their D code.) I don't have any experience working in D, though I have researched the language - it has some nice features, and it was willing to break more compatibility with C in pursuit of a cleaner language than C++ was. But there's a lot it can't do for my needs, and C++ is a far better choice for my work. However, apart from D's use of modules rather than an "include" mechanism (C++ has modules now, but they are not common in practice as yet), I don't believe there are any features of D that replace C preprocessor uses where there is not a direct equivalent in C++. So I believe that my use of the C preprocessor in my C++ programming is a reasonable model for where I think the preprocessor is useful in C++, and where I would miss it if I were to program in D. I'm excluding includes and their guards, and anything relating to mixing C and C++ (even though that is a very important feature in my work, and it relies heavily on the preprocessor). I use macros for things like "Assert" and "Panic", where the controlling expression gets "stringified" and the function name, file and line numbers are included in the message that is printed and stored in logs. You can't do that without a preprocessor, unless the language supports a level of reflection well beyond the very limited forms found in D and C++ (and even the proposals for C++). I use macros for giving neater names to things that can't be made as functions, constants, etc., such as gcc __attributes__ or C++ attributes, or lists of pragmas, especially in connection with conditional compilation to adapt to different compilers or platforms. I use macros if I need to replace something temporarily, such as for debugging or tracing part of a program. I use the preprocessor for generating unique names for things that need unique names for the language syntax, but for which I will never refer to by name. The most complex preprocessor stuff I have is probably use of so-called "x-macros". I've used these to build simple command-line interfaces (with commands, sub-commands, and parameters, along with help text) and hierarchical menu systems. Even with templates and compile-time functions in D and C++, you are faced with a lot of duplication and run-time generation of structures if you don't use the preprocessor. These are all - without any doubt - "sensible" uses of the preprocessor that are not replaced at all in D or the C++ core language. Of course it is always possible to live without them, but why would anyone want to if the preprocessor is the best tool for the job? > > But I tend to come across the ones where macros are overused or abused. > Some people seem to delight in doing so. Any feature that can be used, can be overused or abused. And there will always be people who delight in writing smart-arse code, as well as people who write bad code unintentionally. Macros are in no way special, and banning them does not make code better. > > When working the Lua sources a few months ago, that makes heavy uses of > macros defined in lower case which look just like functions calls. > That's fine, if they also act just like function calls. The all-caps convention is - IMHO - a terrible idea, and makes code unnecessarily hard to read. All-caps names should be reserved for macros that /don't/ act the way they appear - not for simple constant defines, or function-like macros that act like functions. They should be used as a warning that something special is going on. > One complex expression that my compiler had trouble with, when expanded, > resulted in a line hundreds of character long, and using 11 levels of > nested parentheses, the most I've ever come across. > That's great - something that can help you find bugs or unnecessary limits in your compiler. > I really doubt that the authors would have written code that convoluted > if macros had not been available. > They didn't write convoluted code - they use the tools the C language provides to write code that is the best they could, for whatever value of "best" they were using (most efficient, most maintainable, most portable, etc.). > >>> Typedefs are scoped, string >>> macros are not. >> >> True. Sometimes that is an advantage, sometimes a disadvantage. > > When it is an advantage? If you want to have something that works outside of scopes, being unscoped is an advantage. It does not happen often, but it happens. Maybe you've got functions that needs a lot of calculations, using lines that follow a similar pattern. Putting those patterns in a macro saves repetition in the source code, reduces the risk of errors, and makes the whole thing clearer. But if the identifiers in the pattern have different scopes when they are used (perhaps they are in different functions), you can take advantage of macros' independence of scopes to avoid having to pass local data as parameters. > > My systems language only acquired macros with parameters a year or two > ago. They can only be used to expand to well-formed terms of > expressions, and are used very sparingly. > > They have normal scoping, so can be shadowed or have distinct versions > in different scopes and functions can define their own macros; they can > be imported or exported just like functions and variables. > So why not just use functions? Or implement more advanced core language features, like templates? The point of C preprocessor macros - the reason that they are useful in ways that cannot be handled by core language features - is that they are purely textual. They exist outside of scoping, and language syntax. They can have unmatched brackets, or construct identifiers on the fly, or do all kinds of manipulation of code. That allows for very powerful uses - and, of course, abuses. It is certainly the case that some common uses of macros in C have been made redundant by better language features in C++, D, and even in later versions of C. Most common uses of #define'd constants are better handled by "static const" or "enum". Most function-like macros are better handled by static inline functions, or C++/D templates. Ugly C90/C99 style static_assert macros are best done with real _Static_assert from C11. Many "tricks" that previously needed macros to get efficient code generation are made unnecessary by modern optimising compilers. So if you compare decades-old C code with modern C++, you should see a dramatic reduction in macros and pre-processor usage. Once C++ modules gain common usage, another big pre-processor usage will go. But there will still be uses for it, and situations where it really does give the best way to write the source code. > The sorts of macros that C has seem stone age by comparison. And crude, > in being able to define random bits of syntax, or synthesise tokens from > multiple parts. You say "crude", others say "powerful" and "flexible". The others would be right. > > Some people will obviously love that, but imagine trying to search for > some token with a text editor, but it won't find it because it only > exists after preprocessing. > Imagine /not/ having macros, and having to type out those tokens again and again, when a macro could be defined once. Then imagine wanting to change the tokens, and having to do so everywhere in the code instead of once in the definition. It is not often that you get a free lunch - power and flexibility in one way will often limit things in other ways. There are always tradeoffs, with all features, in all languages - I would have thought you might have learned that by now. > >> Like any powerful tool, macros can be abused or misused, leading to >> poorer results - but that does not mean they are "nothing but trouble". > > I wouldn't use the work 'powerful'; 'dangerous' and 'crazy' might be > more apt. You are scared to learn, and scared that other people see and do things differently, with the result that you limit yourself pointlessly. > > Imagine a CPP that could also map one letter another; more 'powerful', > or just more 'crazy'? > There /are/ preprocessors that can deal with single letters. They can be useful when dealing with code in different character sets, such as converting back and forth between non-ASCII unicode characters and \u sequences. It is poor /uses/ of the C preprocessor that is "crazy" - not the preprocessor or good uses of it. The same applies to every other feature of every (real) programming language ever made.
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> |
|---|---|
| Date | 2024-01-02 15:04 +0000 |
| Message-ID | <pan$436bd$21d2718e$6398bb8c$878dabbf@invalid.invalid> |
| In reply to | #379778 |
David Brown wrote: >> When working the Lua sources a few months ago, that makes heavy uses of >> macros defined in lower case which look just like functions calls. >> >> > That's fine, if they also act just like function calls. There'sn't any such thing. -- Blue-Maned_Hawkâshortens to Hawkâ/blu.mÃin.dðak/ âhe/him/his/himself/Mr. blue-maned_hawk.srht.site 20% of the things cause 80% of the bad.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-02 16:12 +0000 |
| Message-ID | <un1clg$2oq9u$1@dont-email.me> |
| In reply to | #379778 |
On 02/01/2024 10:42, David Brown wrote:
> On 01/01/2024 16:54, Bart wrote:
> I use macros for things like "Assert" and "Panic", where the controlling
> expression gets "stringified" and the function name, file and line
> numbers are included in the message that is printed and stored in logs.
> You can't do that without a preprocessor, unless the language supports a
> level of reflection well beyond the very limited forms found in D and
> C++ (and even the proposals for C++).
>
> I use macros for giving neater names to things that can't be made as
> functions, constants, etc., such as gcc __attributes__ or C++
> attributes, or lists of pragmas, especially in connection with
> conditional compilation to adapt to different compilers or platforms.
>
> I use macros if I need to replace something temporarily, such as for
> debugging or tracing part of a program.
>
> I use the preprocessor for generating unique names for things that need
> unique names for the language syntax, but for which I will never refer
> to by name.
>
> The most complex preprocessor stuff I have is probably use of so-called
> "x-macros". I've used these to build simple command-line interfaces
> (with commands, sub-commands, and parameters, along with help text) and
> hierarchical menu systems.
X-macro are ugly. They are unreadable. At best, if someone has already
done the hard work of setting up a working set of macros, then you will
be able to see how to modify, add or delete entries.
For the purposes of creating parallel sets of enums and associated data,
I use special syntax which makes for a clearer and simpler feature.
Have you ever considered that if C didn't have macros, or they weren't
powerful, then it could have evolved superior, built-in alternatives?
>> One complex expression that my compiler had trouble with, when
>> expanded, resulted in a line hundreds of character long, and using
>> 11 levels of nested parentheses, the most I've ever come across.
>>
>
> That's great - something that can help you find bugs or unnecessary
> limits in your compiler.
It wasn't a compiler limit - it was mine! The resulting expression was
completely unreadable. In the end I resorted to looking at the AST as
that was clearer than C source code.
> If you want to have something that works outside of scopes, being
> unscoped is an advantage. It does not happen often, but it happens.
> Maybe you've got functions that needs a lot of calculations, using lines
> that follow a similar pattern. Putting those patterns in a macro saves
> repetition in the source code, reduces the risk of errors, and makes the
> whole thing clearer. But if the identifiers in the pattern have
> different scopes when they are used (perhaps they are in different
> functions), you can take advantage of macros' independence of scopes to
> avoid having to pass local data as parameters.
The scope I'm talking about is the name of the macro, not that of the
macro parameters.
>> They have normal scoping, so can be shadowed or have distinct versions
>> in different scopes and functions can define their own macros; they
>> can be imported or exported just like functions and variables.
>>
>
> So why not just use functions?
There are a few uses where functions won't work or would be inefficient.
My macros are easier to implement than inlined functions.
Half my use-cases involve inline assembly. Others involve creating
aliases for things like module names:
module mm_mcldecls as md
Now I can use md.F to disambiguate F instead of mm_mcldecls.F (when F is
exported by more than one module). Here the macro mechanism is used
internally.
The alternative here would be a special-purpose 'alias' feature but this
seems to work too.
> Or implement more advanced core language
> features, like templates?
>
> The point of C preprocessor macros - the reason that they are useful in
> ways that cannot be handled by core language features - is that they are
> purely textual. They exist outside of scoping, and language syntax.
> They can have unmatched brackets, or construct identifiers on the fly,
> or do all kinds of manipulation of code. That allows for very powerful
> uses - and, of course, abuses.
Even when not being abused, their very use can cause problems, for
example when they appear in APIs for libraries that could be used across
an FFI.
Macros are a C language artefact, and what they expand to is arbitrary
C syntax that can be meaningless elsewhere.
(When I processed the GTK headers from 350,000 lines of C to 25,000
lines in my syntax, the last 4,000 lines were C macros that weren't
identifiable as simple named literals (eg #define A 100) and that would
need dealing with manually.)
> It is certainly the case that some common uses of macros in C have been
> made redundant by better language features in C++, D, and even in later
> versions of C. Most common uses of #define'd constants are better
> handled by "static const" or "enum". Most function-like macros are
> better handled by static inline functions, or C++/D templates. Ugly
> C90/C99 style static_assert macros are best done with real
> _Static_assert from C11. Many "tricks" that previously needed macros to
> get efficient code generation are made unnecessary by modern optimising
> compilers.
>
> So if you compare decades-old C code with modern C++, you should see a
> dramatic reduction in macros and pre-processor usage.
I haven't noticed. Things are bad enough now; are you saying they were
worse?
> You say "crude", others say "powerful" and "flexible". The others would
> be right.
It's crude for many reasons, here's one:
#define x y
That is intended to replace instances of the top level name 'x' with
'y'. But in C, it also replaces 'x' in 'p.x' with 'p.y'.
In fact, any macro name you create is at risk of clashing with struct
member names. Such names are usually considered safe in a private
namespace; not in C!
>>
>> Some people will obviously love that, but imagine trying to search for
>> some token with a text editor, but it won't find it because it only
>> exists after preprocessing.
>>
>
> Imagine /not/ having macros, and having to type out those tokens again
> and again, when a macro could be defined once. Then imagine wanting to
> change the tokens, and having to do so everywhere in the code instead of
> once in the definition.
I don't like macros, even the advanced ones in modern languages. I
consider them an anti-feature. And I did without them for decades, other
than for a time, simple ones with no parameters were used.
The parameterised ones I have now are an experiment. But every time I
use one, I get the same feeling as when I write 'goto'.
> It is not often that you get a free lunch - power and flexibility in one
> way will often limit things in other ways. There are always tradeoffs,
> with all features, in all languages - I would have thought you might
> have learned that by now.
It's not a free lunch. A full CPP is quite difficult to implement,
possibly harder than C itself. The one I have is perhaps 90% there; it
will not do esoteric stuff.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-02 18:34 +0100 |
| Message-ID | <un1hek$2ph62$1@dont-email.me> |
| In reply to | #379783 |
On 02/01/2024 17:12, Bart wrote: > On 02/01/2024 10:42, David Brown wrote: >> On 01/01/2024 16:54, Bart wrote: > > >> I use macros for things like "Assert" and "Panic", where the >> controlling expression gets "stringified" and the function name, file >> and line numbers are included in the message that is printed and >> stored in logs. You can't do that without a preprocessor, unless the >> language supports a level of reflection well beyond the very limited >> forms found in D and C++ (and even the proposals for C++). >> >> I use macros for giving neater names to things that can't be made as >> functions, constants, etc., such as gcc __attributes__ or C++ >> attributes, or lists of pragmas, especially in connection with >> conditional compilation to adapt to different compilers or platforms. >> >> I use macros if I need to replace something temporarily, such as for >> debugging or tracing part of a program. >> >> I use the preprocessor for generating unique names for things that >> need unique names for the language syntax, but for which I will never >> refer to by name. >> >> The most complex preprocessor stuff I have is probably use of >> so-called "x-macros". I've used these to build simple command-line >> interfaces (with commands, sub-commands, and parameters, along with >> help text) and hierarchical menu systems. > > X-macro are ugly. They are unreadable. Speaking as someone who has used them in real code, rather than someone with a pathological hatred of macros and who prefers knee-jerk reaction to their uses instead of applying a few minutes objective thought, "x-macros" can make code significantly simpler, clearer, and much easier to maintain correctly. > At best, if someone has already > done the hard work of setting up a working set of macros, then you will > be able to see how to modify, add or delete entries. They are not hard. Perhaps you don't actually understand what is usually meant by "x-macros" ? > > For the purposes of creating parallel sets of enums and associated data, > I use special syntax which makes for a clearer and simpler feature. And that is, obviously, utterly useless - because it is not C or even a commonly supported extension. Oh, and even if it /were/ part of C, it would not help because that's not what I was doing. > > Have you ever considered that if C didn't have macros, or they weren't > powerful, then it could have evolved superior, built-in alternatives? > The C preprocessor is part of C - it is already built in. But I have already mentioned, several times, how other language features of C and C++ are better choices than macros for the uses that they cover. Or does your desperate need to rant against C and macros blind you to reading other people's posts? (I'd appreciate an answer here - it will let me know if there is any point in trying to educate you or answer your questions.) > >>> One complex expression that my compiler had trouble with, when >>> expanded, resulted in a line hundreds of character long, and using >>> 11 levels of nested parentheses, the most I've ever come across. >>> >> >> That's great - something that can help you find bugs or unnecessary >> limits in your compiler. > > It wasn't a compiler limit - it was mine! The resulting expression was > completely unreadable. I wonder if the code authors also found this expanded expression unreadable. I guess not - because they used macros so that they could write it in a clear and understandable way, and never have to look at the expansion! You don't seem to comprehend the point of macros at all. > In the end I resorted to looking at the AST as > that was clearer than C source code. > Why not just look at the code as written, if you want to understand it? Or would doing something that sensible put a damper on your rants? >> If you want to have something that works outside of scopes, being >> unscoped is an advantage. It does not happen often, but it happens. >> Maybe you've got functions that needs a lot of calculations, using >> lines that follow a similar pattern. Putting those patterns in a >> macro saves repetition in the source code, reduces the risk of errors, >> and makes the whole thing clearer. But if the identifiers in the >> pattern have different scopes when they are used (perhaps they are in >> different functions), you can take advantage of macros' independence >> of scopes to avoid having to pass local data as parameters. > > The scope I'm talking about is the name of the macro, not that of the > macro parameters. > I was talking about the scope of parameters and any identifiers in the macro definition. For the name of the macro itself, I can agree that I don't see any advantage in it being scope-free. I can't think off-hand of a situation where it would be particularly useful to define a macro inside a block scope in a function and have it work outside that scope too. (It's obvious why macro names cannot be scoped.) > >>> They have normal scoping, so can be shadowed or have distinct >>> versions in different scopes and functions can define their own >>> macros; they can be imported or exported just like functions and >>> variables. >>> >> >> So why not just use functions? > > There are a few uses where functions won't work or would be inefficient. If functions are inefficient, that is a weakness in your compilation. Don't you do any kind of inlining or inter-procedural optimisations? I realise these are not easy to implement, but the potential gains are significant. > My macros are easier to implement than inlined functions. > So they are like a limited form of inline functions? Okay, that might be useful to get better code from a weaker compiler, but that's hardly a benefit compared to real macros. > Half my use-cases involve inline assembly. Why can't that be in inlined functions? Again, you are not showing that these limited macros have any benefits compared to what is found in C, you are merely saying you have something that partially counters the limitations of your tools. (And to be clear - I fully appreciate that making advanced compiler optimisations is very difficult, and this is a good solution for you when making everything yourself. But it is not a positive feature or selling point for your language - it is a workaround for practical limitations.) > Others involve creating > aliases for things like module names: > > module mm_mcldecls as md > > Now I can use md.F to disambiguate F instead of mm_mcldecls.F (when F is > exported by more than one module). Here the macro mechanism is used > internally. Aliases in module imports are common (and useful) in many languages. They are not "macros" in any sense. > > The alternative here would be a special-purpose 'alias' feature but this > seems to work too. > It is completely irrelevant how this is all implemented internally. It doesn't matter if it is done using the same bit of code that handles your limited macros, or if it is something else entirely. It only matters how it works to the language user - and it's a module alias, not a macro. >> Or implement more advanced core language features, like templates? >> >> The point of C preprocessor macros - the reason that they are useful >> in ways that cannot be handled by core language features - is that >> they are purely textual. They exist outside of scoping, and language >> syntax. They can have unmatched brackets, or construct identifiers on >> the fly, or do all kinds of manipulation of code. That allows for >> very powerful uses - and, of course, abuses. > > Even when not being abused, their very use can cause problems, for > example when they appear in APIs for libraries that could be used across > an FFI. > C code is written for use in C. Limitations or quirks of other languages that try to interface to that code are not the responsibility of the C language. People writing code in one language with the intention of having it reusable in other languages have a responsibility to try to make this simpler. (Just as people writing reusable library code have a responsibility to document the code more than they might for a self-contained project.) > Macros are a C language artefact, and what they expand to is arbitrary C > syntax that can be meaningless elsewhere. Yes - C code is C code. It is not Pascal, or Fortran, or Ada. Should this be a surprise? > > (When I processed the GTK headers from 350,000 lines of C to 25,000 > lines in my syntax, the last 4,000 lines were C macros that weren't > identifiable as simple named literals (eg #define A 100) and that would > need dealing with manually.) > > >> It is certainly the case that some common uses of macros in C have >> been made redundant by better language features in C++, D, and even in >> later versions of C. Most common uses of #define'd constants are >> better handled by "static const" or "enum". Most function-like macros >> are better handled by static inline functions, or C++/D templates. >> Ugly C90/C99 style static_assert macros are best done with real >> _Static_assert from C11. Many "tricks" that previously needed macros >> to get efficient code generation are made unnecessary by modern >> optimising compilers. >> >> So if you compare decades-old C code with modern C++, you should see a >> dramatic reduction in macros and pre-processor usage. > I haven't noticed. Things are bad enough now; are you saying they were > worse? > You already have a habit of cherry-picking example code that is as "Bart-unfriendly" as you can find. And of course you'd really get your knickers in a twist if you looked at modern C++ code, even if it had little or no macros. >> You say "crude", others say "powerful" and "flexible". The others >> would be right. > > It's crude for many reasons, here's one: > > #define x y > > That is intended to replace instances of the top level name 'x' with > 'y'. But in C, it also replaces 'x' in 'p.x' with 'p.y'. > Yes. If you don't like that, don't make such a macro. > In fact, any macro name you create is at risk of clashing with struct > member names. Such names are usually considered safe in a private > namespace; not in C! C has quite limited namespaces, and you have to be careful to avoid clashes. Live with it - other people do. (Better namespaces is one of the reasons I prefer C++.) > >>> >>> Some people will obviously love that, but imagine trying to search >>> for some token with a text editor, but it won't find it because it >>> only exists after preprocessing. >>> >> >> Imagine /not/ having macros, and having to type out those tokens again >> and again, when a macro could be defined once. Then imagine wanting >> to change the tokens, and having to do so everywhere in the code >> instead of once in the definition. > > I don't like macros, even the advanced ones in modern languages. I > consider them an anti-feature. And I did without them for decades, other > than for a time, simple ones with no parameters were used. > > The parameterised ones I have now are an experiment. But every time I > use one, I get the same feeling as when I write 'goto'. > >> It is not often that you get a free lunch - power and flexibility in >> one way will often limit things in other ways. There are always >> tradeoffs, with all features, in all languages - I would have thought >> you might have learned that by now. > > It's not a free lunch. Exactly my point. (I can see how my wording could be misinterpreted here as suggesting that macros /are/ a free lunch. Sorry about that.) > A full CPP is quite difficult to implement, > possibly harder than C itself. I don't have your experience, but I find that /very/ hard to believe. I should imagine it's primarily a matter of working through the "translation phases" and "preprocessing directives" described in the C standards, step by step. There's plenty of scope for making things harder by aiming for greater efficiency and/or fewer passes through the code, but that's a matter of choice, and it pales in comparison to the scope for complications and optimisations in the main part of the compilation. > The one I have is perhaps 90% there; it > will not do esoteric stuff. > Such as?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-02 20:24 +0000 |
| Message-ID | <un1rdk$2quec$1@dont-email.me> |
| In reply to | #379785 |
On 02/01/2024 17:34, David Brown wrote:
> On 02/01/2024 17:12, Bart wrote:
>> X-macro are ugly. They are unreadable.
>
> Speaking as someone who has used them in real code, rather than someone
> with a pathological hatred of macros and who prefers knee-jerk reaction
> to their uses instead of applying a few minutes objective thought,
> "x-macros" can make code significantly simpler, clearer, and much easier
> to maintain correctly.
I'm sorry, but I *DO* find them utterly impossible. This is a simple
example from Stackoverflow of someone wanting to define a set of enums
with an accompanying table, whose problem was in ensuring the two were
kept in sync.
The X-macro solution was this, adapted from the first answer here
(https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros);
assume those functions are in scope:
-------
#define STATE_TABLE \
ENTRY(STATE0, func0) \
ENTRY(STATE1, func1) \
ENTRY(STATE2, func2) \
ENTRY(STATE3, func3) \
enum
{
#define ENTRY(a,b) a,
STATE_TABLE
#undef ENTRY
NUM_STATES
};
void* jumptable[NUM_STATES] =
{
#define ENTRY(a,b) b,
STATE_TABLE
#undef ENTRY
};
-------
With my feature, it is merely this:
global enumdata []ref void jumptable =
(state1, func1), # comment 1
(state2, func2),
(state3, func3), # comment 3
(state4, func4),
end
Notice:
(1) I don't need any of those weird macros.
(2) I don't need those backslashes
(3) I can add comments to any entry in the table.
(4) The 'global' attribute means both enumeration names and the array
are exported to other modules. Doing the same in C is tricky.
But I'm wasting my time because you are never going to admit my feature
is superior to X-macros for this purpose.
(The author of this example goes on to say how it can also be used to
define a set of function prototypes. I can't do that with my feature.
But then I don't need function prototypes!)
>> At best, if someone has already done the hard work of setting up a
>> working set of macros, then you will be able to see how to modify, add
>> or delete entries.
>
> They are not hard.
Maybe not for you, but it would take me ages to come up with the right
incantations to make it work.
>> For the purposes of creating parallel sets of enums and associated
>> data, I use special syntax which makes for a clearer and simpler feature.
>
> And that is, obviously, utterly useless - because it is not C or even a
> commonly supported extension. Oh, and even if it /were/ part of C, it
> would not help because that's not what I was doing.
I've given an example of a use-case for C macros which have a special
purpose feature in other languages. So of cause it's not in C.
>>
>> Have you ever considered that if C didn't have macros, or they weren't
>> powerful, then it could have evolved superior, built-in alternatives?
>>
>
> The C preprocessor is part of C - it is already built in.
You missed my point. Take a tiny feature like being able to easily get
the size of a fixed-length array. You commonly see macro like this:
#define LENGTH(a) (sizeof(a)/size(a[0]))
What incentive is there to properly add a built-in way to do that, when
it can be done, badly, and in 1000 different ways by each user, in a
one-line macro?
Another example is GETBIT(a, n).
>> It wasn't a compiler limit - it was mine! The resulting expression was
>> completely unreadable.
>
> I wonder if the code authors also found this expanded expression
> unreadable.
Look at the example I posted in reply to Blue-Maned_Hawk.
In particular consider my last comment.
> I guess not - because they used macros so that they could
> write it in a clear and understandable way, and never have to look at
> the expansion! You don't seem to comprehend the point of macros at all.
>
>> In the end I resorted to looking at the AST as that was clearer than C
>> source code.
>>
>
> Why not just look at the code as written, if you want to understand it?
In my case I was debugging my C compiler. Then you need to examine the
actual expanded code in detail. Excessive use of macros makes that much
harder.
That example came from Lua 5.4, an interpeter whose performance on a par
with my own product running from HLL-only code. That doesn't doesn't use
deeply-nested macro like this, and it doesn't appear to suffer,.
> Or would doing something that sensible put a damper on your rants?
Look, I'm written a C preprocessor (I suspect you haven't). If I wanted,
I could adapt it to work on my own languages.
But I /don't/ want to. Obviously I see something undesirable about them
(I don't like metaprogramming in general; people get too carried away
with it and want to show off their skills).
Why can't you accept that?
>> Half my use-cases involve inline assembly.
>
> Why can't that be in inlined functions?
That doesn't work in inline assembly.
> Again, you are not showing that
> these limited macros have any benefits compared to what is found in C,
That's true. I can't write something like:
#define M a+b)*c
(M;
>> Macros are a C language artefact, and what they expand to is arbitrary
>> C syntax that can be meaningless elsewhere.
>
> Yes - C code is C code. It is not Pascal, or Fortran, or Ada. Should
> this be a surprise?
It's inconvenient. This is a macro from SDL2:
#define SDL_CompilerBarrier() \
{ SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
SDL_AtomicUnlock(&_tmp); }
Rather than declaring a function which resides in a language-neutral
DLL, it declares it here, in the form of actual C code.
Even given a language with an FFI that is capable of calling external
functions compiled as C, what are they supposed to do with this?
That example was in a conditional block; I don't know the context. But
here's a juicy one that is the result of an attempt to automatically
translate the C SDL2 API to my syntax:
global macro SDL_FOURCC(A,B,C,D) =
((SDL_static_cast(Uint32,SDL_static_cast(Uint8,(A)))<<0)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(B)))<<8)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(C)))<<16)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(D)))<<24))
This also contains arbitrary C code; it needs a much more sophisticated
tool than one that just does declaration. Basically a transpiler from
C to the language one is writing bindinds for.
> You already have a habit of cherry-picking example code that is as
> "Bart-unfriendly" as you can find.
Try testing your own C compiler on just about any codebase. You don't
have to look far for extreme examples.
> I don't have your experience, but I find that /very/ hard to believe. I
> should imagine it's primarily a matter of working through the
> "translation phases" and "preprocessing directives" described in the C
> standards, step by step.
The C standard has very little to say about. I once found a very, very
long article which went into considerably more detail, now lost.
But even 1/3 through I decided that it was impossible.
In 2017 when I created my CPP, many compilers would give different
results with various edge cases of macros. Which were right and which
were wrong? You'd think there'd be a definitive reference for it.
Here's an example I've just found:
#include <stdio.h>
int main(void) {
#define FOO
#define BAR defined(FOO)
#if BAR
puts("BAR");
#else
puts("FOO");
#endif
}
Most compilers will display BAR; MSVC I think is the only one showing
FOO. (Some smaller compilers I tried on godbolt.org failed to compile it.)
Mine showed BAR (obviously!)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-02 13:00 -0800 |
| Message-ID | <un1tgr$2r75b$1@dont-email.me> |
| In reply to | #379794 |
On 1/2/2024 12:24 PM, Bart wrote:
> On 02/01/2024 17:34, David Brown wrote:
>> On 02/01/2024 17:12, Bart wrote:
>
>>> X-macro are ugly. They are unreadable.
>>
>> Speaking as someone who has used them in real code, rather than
>> someone with a pathological hatred of macros and who prefers knee-jerk
>> reaction to their uses instead of applying a few minutes objective
>> thought, "x-macros" can make code significantly simpler, clearer, and
>> much easier to maintain correctly.
>
>
> I'm sorry, but I *DO* find them utterly impossible. This is a simple
> example from Stackoverflow of someone wanting to define a set of enums
> with an accompanying table, whose problem was in ensuring the two were
> kept in sync.
>
> The X-macro solution was this, adapted from the first answer here
> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>
> -------
>
> #define STATE_TABLE \
> ENTRY(STATE0, func0) \
> ENTRY(STATE1, func1) \
> ENTRY(STATE2, func2) \
> ENTRY(STATE3, func3) \
>
> enum
> {
> #define ENTRY(a,b) a,
> STATE_TABLE
> #undef ENTRY
> NUM_STATES
> };
>
> void* jumptable[NUM_STATES] =
> {
> #define ENTRY(a,b) b,
> STATE_TABLE
> #undef ENTRY
> };
> -------
>
>
> With my feature, it is merely this:
>
> global enumdata []ref void jumptable =
> (state1, func1), # comment 1
> (state2, func2),
> (state3, func3), # comment 3
> (state4, func4),
> end
>
> Notice:
>
> (1) I don't need any of those weird macros.
>
> (2) I don't need those backslashes
>
> (3) I can add comments to any entry in the table.
>
> (4) The 'global' attribute means both enumeration names and the array
> are exported to other modules. Doing the same in C is tricky.
>
> But I'm wasting my time because you are never going to admit my feature
> is superior to X-macros for this purpose.
>
> (The author of this example goes on to say how it can also be used to
> define a set of function prototypes. I can't do that with my feature.
> But then I don't need function prototypes!)
>
>>> At best, if someone has already done the hard work of setting up a
>>> working set of macros, then you will be able to see how to modify,
>>> add or delete entries.
>>
>> They are not hard.
>
> Maybe not for you, but it would take me ages to come up with the right
> incantations to make it work.
>
>>> For the purposes of creating parallel sets of enums and associated
>>> data, I use special syntax which makes for a clearer and simpler
>>> feature.
>>
>> And that is, obviously, utterly useless - because it is not C or even
>> a commonly supported extension. Oh, and even if it /were/ part of C,
>> it would not help because that's not what I was doing.
>
> I've given an example of a use-case for C macros which have a special
> purpose feature in other languages. So of cause it's not in C.
>
>>>
>>> Have you ever considered that if C didn't have macros, or they
>>> weren't powerful, then it could have evolved superior, built-in
>>> alternatives?
>>>
>>
>> The C preprocessor is part of C - it is already built in.
>
> You missed my point. Take a tiny feature like being able to easily get
> the size of a fixed-length array. You commonly see macro like this:
>
> #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> What incentive is there to properly add a built-in way to do that, when
> it can be done, badly, and in 1000 different ways by each user, in a
> one-line macro?
>
> Another example is GETBIT(a, n).
>
>>> It wasn't a compiler limit - it was mine! The resulting expression
>>> was completely unreadable.
>>
>> I wonder if the code authors also found this expanded expression
>> unreadable.
>
> Look at the example I posted in reply to Blue-Maned_Hawk.
>
> In particular consider my last comment.
>
>
>> I guess not - because they used macros so that they could write it in
>> a clear and understandable way, and never have to look at the
>> expansion! You don't seem to comprehend the point of macros at all.
>>
>>> In the end I resorted to looking at the AST as that was clearer than
>>> C source code.
>>>
>>
>> Why not just look at the code as written, if you want to understand it?
>
> In my case I was debugging my C compiler. Then you need to examine the
> actual expanded code in detail. Excessive use of macros makes that much
> harder.
>
> That example came from Lua 5.4, an interpeter whose performance on a par
> with my own product running from HLL-only code. That doesn't doesn't use
> deeply-nested macro like this, and it doesn't appear to suffer,.
>
>
>> Or would doing something that sensible put a damper on your rants?
>
> Look, I'm written a C preprocessor (I suspect you haven't). If I wanted,
> I could adapt it to work on my own languages.
>
> But I /don't/ want to. Obviously I see something undesirable about them
> (I don't like metaprogramming in general; people get too carried away
> with it and want to show off their skills).
>
> Why can't you accept that?
>
>
>>> Half my use-cases involve inline assembly.
>>
>> Why can't that be in inlined functions?
>
> That doesn't work in inline assembly.
>
>> Again, you are not showing that these limited macros have any benefits
>> compared to what is found in C,
>
> That's true. I can't write something like:
>
> #define M a+b)*c
>
> (M;
>
>
>>> Macros are a C language artefact, and what they expand to is
>>> arbitrary C syntax that can be meaningless elsewhere.
>>
>> Yes - C code is C code. It is not Pascal, or Fortran, or Ada. Should
>> this be a surprise?
>
> It's inconvenient. This is a macro from SDL2:
>
> #define SDL_CompilerBarrier() \
> { SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
> SDL_AtomicUnlock(&_tmp); }
Why in the world would a compiler barrier need any atomics? I need to
study up on this wrt SDL.
>
> Rather than declaring a function which resides in a language-neutral
> DLL, it declares it here, in the form of actual C code.
>
> Even given a language with an FFI that is capable of calling external
> functions compiled as C, what are they supposed to do with this?
>
> That example was in a conditional block; I don't know the context. But
> here's a juicy one that is the result of an attempt to automatically
> translate the C SDL2 API to my syntax:
>
> global macro SDL_FOURCC(A,B,C,D) =
> ((SDL_static_cast(Uint32,SDL_static_cast(Uint8,(A)))<<0)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(B)))<<8)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(C)))<<16)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(D)))<<24))
>
> This also contains arbitrary C code; it needs a much more sophisticated
> tool than one that just does declaration. Basically a transpiler from
> C to the language one is writing bindinds for.
>
>
>> You already have a habit of cherry-picking example code that is as
>> "Bart-unfriendly" as you can find.
>
> Try testing your own C compiler on just about any codebase. You don't
> have to look far for extreme examples.
>
>> I don't have your experience, but I find that /very/ hard to believe.
>> I should imagine it's primarily a matter of working through the
>> "translation phases" and "preprocessing directives" described in the C
>> standards, step by step.
>
> The C standard has very little to say about. I once found a very, very
> long article which went into considerably more detail, now lost.
>
> But even 1/3 through I decided that it was impossible.
>
> In 2017 when I created my CPP, many compilers would give different
> results with various edge cases of macros. Which were right and which
> were wrong? You'd think there'd be a definitive reference for it.
>
> Here's an example I've just found:
>
> #include <stdio.h>
> int main(void) {
>
> #define FOO
> #define BAR defined(FOO)
> #if BAR
> puts("BAR");
> #else
> puts("FOO");
> #endif
> }
>
> Most compilers will display BAR; MSVC I think is the only one showing
> FOO. (Some smaller compilers I tried on godbolt.org failed to compile it.)
>
> Mine showed BAR (obviously!)
>
>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-01-02 13:02 -0800 |
| Message-ID | <un1tkm$2r75b$2@dont-email.me> |
| In reply to | #379796 |
On 1/2/2024 1:00 PM, Chris M. Thomasson wrote:
> On 1/2/2024 12:24 PM, Bart wrote:
>> On 02/01/2024 17:34, David Brown wrote:
>>> On 02/01/2024 17:12, Bart wrote:
>>
>>>> X-macro are ugly. They are unreadable.
>>>
>>> Speaking as someone who has used them in real code, rather than
>>> someone with a pathological hatred of macros and who prefers
>>> knee-jerk reaction to their uses instead of applying a few minutes
>>> objective thought, "x-macros" can make code significantly simpler,
>>> clearer, and much easier to maintain correctly.
>>
>>
>> I'm sorry, but I *DO* find them utterly impossible. This is a simple
>> example from Stackoverflow of someone wanting to define a set of enums
>> with an accompanying table, whose problem was in ensuring the two were
>> kept in sync.
>>
>> The X-macro solution was this, adapted from the first answer here
>> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>>
>> -------
>>
>> #define STATE_TABLE \
>> ENTRY(STATE0, func0) \
>> ENTRY(STATE1, func1) \
>> ENTRY(STATE2, func2) \
>> ENTRY(STATE3, func3) \
>>
>> enum
>> {
>> #define ENTRY(a,b) a,
>> STATE_TABLE
>> #undef ENTRY
>> NUM_STATES
>> };
>>
>> void* jumptable[NUM_STATES] =
>> {
>> #define ENTRY(a,b) b,
>> STATE_TABLE
>> #undef ENTRY
>> };
>> -------
>>
>>
>> With my feature, it is merely this:
>>
>> global enumdata []ref void jumptable =
>> (state1, func1), # comment 1
>> (state2, func2),
>> (state3, func3), # comment 3
>> (state4, func4),
>> end
>>
>> Notice:
>>
>> (1) I don't need any of those weird macros.
>>
>> (2) I don't need those backslashes
>>
>> (3) I can add comments to any entry in the table.
>>
>> (4) The 'global' attribute means both enumeration names and the array
>> are exported to other modules. Doing the same in C is tricky.
>>
>> But I'm wasting my time because you are never going to admit my
>> feature is superior to X-macros for this purpose.
>>
>> (The author of this example goes on to say how it can also be used to
>> define a set of function prototypes. I can't do that with my feature.
>> But then I don't need function prototypes!)
>>
>>>> At best, if someone has already done the hard work of setting up a
>>>> working set of macros, then you will be able to see how to modify,
>>>> add or delete entries.
>>>
>>> They are not hard.
>>
>> Maybe not for you, but it would take me ages to come up with the right
>> incantations to make it work.
>>
>>>> For the purposes of creating parallel sets of enums and associated
>>>> data, I use special syntax which makes for a clearer and simpler
>>>> feature.
>>>
>>> And that is, obviously, utterly useless - because it is not C or even
>>> a commonly supported extension. Oh, and even if it /were/ part of C,
>>> it would not help because that's not what I was doing.
>>
>> I've given an example of a use-case for C macros which have a special
>> purpose feature in other languages. So of cause it's not in C.
>>
>>>>
>>>> Have you ever considered that if C didn't have macros, or they
>>>> weren't powerful, then it could have evolved superior, built-in
>>>> alternatives?
>>>>
>>>
>>> The C preprocessor is part of C - it is already built in.
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>> #define LENGTH(a) (sizeof(a)/size(a[0]))
>>
>> What incentive is there to properly add a built-in way to do that,
>> when it can be done, badly, and in 1000 different ways by each user,
>> in a one-line macro?
>>
>> Another example is GETBIT(a, n).
>>
>>>> It wasn't a compiler limit - it was mine! The resulting expression
>>>> was completely unreadable.
>>>
>>> I wonder if the code authors also found this expanded expression
>>> unreadable.
>>
>> Look at the example I posted in reply to Blue-Maned_Hawk.
>>
>> In particular consider my last comment.
>>
>>
>>> I guess not - because they used macros so that they could write it in
>>> a clear and understandable way, and never have to look at the
>>> expansion! You don't seem to comprehend the point of macros at all.
>>>
>>>> In the end I resorted to looking at the AST as that was clearer than
>>>> C source code.
>>>>
>>>
>>> Why not just look at the code as written, if you want to understand it?
>>
>> In my case I was debugging my C compiler. Then you need to examine the
>> actual expanded code in detail. Excessive use of macros makes that
>> much harder.
>>
>> That example came from Lua 5.4, an interpeter whose performance on a
>> par with my own product running from HLL-only code. That doesn't
>> doesn't use deeply-nested macro like this, and it doesn't appear to
>> suffer,.
>>
>>
>>> Or would doing something that sensible put a damper on your rants?
>>
>> Look, I'm written a C preprocessor (I suspect you haven't). If I
>> wanted, I could adapt it to work on my own languages.
>>
>> But I /don't/ want to. Obviously I see something undesirable about
>> them (I don't like metaprogramming in general; people get too carried
>> away with it and want to show off their skills).
>>
>> Why can't you accept that?
>>
>>
>>>> Half my use-cases involve inline assembly.
>>>
>>> Why can't that be in inlined functions?
>>
>> That doesn't work in inline assembly.
>>
>>> Again, you are not showing that these limited macros have any
>>> benefits compared to what is found in C,
>>
>> That's true. I can't write something like:
>>
>> #define M a+b)*c
>>
>> (M;
>>
>>
>>>> Macros are a C language artefact, and what they expand to is
>>>> arbitrary C syntax that can be meaningless elsewhere.
>>>
>>> Yes - C code is C code. It is not Pascal, or Fortran, or Ada.
>>> Should this be a surprise?
>>
>> It's inconvenient. This is a macro from SDL2:
>>
>> #define SDL_CompilerBarrier() \
>> { SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
>> SDL_AtomicUnlock(&_tmp); }
>
> Why in the world would a compiler barrier need any atomics? I need to
> study up on this wrt SDL.
Compiler barriers are completely different than memory barriers.
[...]
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2024-01-03 00:24 +0100 |
| Message-ID | <un25vp$1qvm$1@news.gegeweb.eu> |
| In reply to | #379794 |
On 1/2/24 21:24, Bart wrote:
>
> You missed my point. Take a tiny feature like being able to easily get
> the size of a fixed-length array. You commonly see macro like this:
>
> #define LENGTH(a) (sizeof(a)/size(a[0]))
And why is that bad? That's a real question.
--
+---------------------------------------------------------------------+
| https://wiki.interhacker.space/index.php?title=Techno-futilit%C3%A9 |
+---------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-03 02:41 +0000 |
| Message-ID | <un2hhn$2vhkg$2@dont-email.me> |
| In reply to | #379799 |
On Wed, 3 Jan 2024 00:24:41 +0100, tTh wrote:
> On 1/2/24 21:24, Bart wrote:
>>
>> #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> And why is that bad? That's a real question.
Ignoring the typo? Not typesafe. If you pass something that it’s not
expecting, you will likely not get a nice, clear error message, but a
cryptic, not to say, irrelevant, one.
Also, would it be better as
#define LENGTH(a) (sizeof(a)/sizeof((a)[0]))
? Answers on a postcard, please.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-03 03:29 +0000 |
| Message-ID | <20240102192925.315@kylheku.com> |
| In reply to | #379799 |
On 2024-01-02, tTh <tth@none.invalid> wrote: > On 1/2/24 21:24, Bart wrote: >> >> You missed my point. Take a tiny feature like being able to easily get >> the size of a fixed-length array. You commonly see macro like this: >> >> #define LENGTH(a) (sizeof(a)/size(a[0])) > > And why is that bad? That's a real question. It fails miserably on pointers, and silently, if you don't have a newer gcc that has a diagnostic specifically for this case. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-03 11:55 +0000 |
| Message-ID | <un3hvm$36jtf$1@dont-email.me> |
| In reply to | #379799 |
On 02/01/2024 23:24, tTh wrote:
> On 1/2/24 21:24, Bart wrote:
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>> #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> And why is that bad? That's a real question.
Where do I start?
* Why is it necessary for a million programmers to each come up with
their own solutions for something so basic? Eg. they will all use
diferent names.
* What happens when you merge or copy&paste code form different sources,
which use different macros for the same thing?
How does it work in practice: does everyone have a personal header full
of this stuff (bits missing from the language)? That will make it
awkward to post short programs to forums as now they have this extra
dependendcy.
Personally I can never bothered to write such macros in throwaway
programs, I just either write the whole thing in situ, or hard-code the
size if I know what it is anyway:
char* names[] = {"one", "two", "three", "four"};
for (int i=0; i<4; ++i)
puts(names[i]);
Rather than write:
for (int i=0; i<sizeof(names)/sizeof(names[0]); ++i) puts(names[i]);
It's all just so messy and annoying.
How hard is it to make it built-in to the language? I tried it just now
and it was about 20 lines of code to allow me to instead write:
char* names[] = {"one", "two", "three", "four"};
for (int i=0; i<lengthof(names); ++i)
puts(names[i]);
It took about 20 minutes. This could have been done in 1972.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-03 15:32 +0000 |
| Message-ID | <Z5flN.88873$vFZa.33923@fx13.iad> |
| In reply to | #379808 |
Bart <bc@freeuk.cm> writes:
>On 02/01/2024 23:24, tTh wrote:
>> On 1/2/24 21:24, Bart wrote:
>>>
>>> You missed my point. Take a tiny feature like being able to easily get
>>> the size of a fixed-length array. You commonly see macro like this:
>>>
>>> #define LENGTH(a) (sizeof(a)/size(a[0]))
>>
>> And why is that bad? That's a real question.
>
>Where do I start?
>
>* Why is it necessary for a million programmers to each come up with
> their own solutions for something so basic? Eg. they will all use
> diferent names.
Why is it necessary to exaggerate?
I've not seen that particular macro in the last forty years, myself.
LENGTH isn't even the proper macro name in this case; QUANTITY or NUM_ELEMENTS
would likely be more appropriate.
I have, of course, seen the idiom used often - it's quite normal and
standard.
e.g.
/*
* Table of Pentium MSR's to allow the Guest to access directly.
*
* XXX - Note that if the guest is allowed to access these MSR's
* directly, then they must be preserved and restored when the
* guest is migrated to a different core.
*/
static int pentium_msr_passthrough[] = {
MSR_SYSENTER_CS,
MSR_SYSENTER_EIP,
MSR_SYSENTER_ESP,
};
static const size_t PENTIUM_MSR_PT_CNT =
sizeof(pentium_msr_passthrough) / sizeof(pentium_msr_passthrough[0]);
/*
* Table of K6 MSR's to allow the guest to access directly.
*
* See caveat above.
*/
static int k6_msr_passthrough[] = {
MSR_KERN_GS_BASE,
MSR_USER_GS_BASE,
MSR_FS_BASE,
MSR_STAR,
MSR_LSTAR,
MSR_CSTAR,
MSR_SFMASK,
MSR_TSC_AUX,
};
static const unsigned int K6_MSR_PT_CNT =
sizeof(k6_msr_passthrough) / sizeof(k6_msr_passthrough[0]);
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-03 17:14 +0000 |
| Message-ID | <un44ln$398sl$1@dont-email.me> |
| In reply to | #379811 |
On 03/01/2024 15:32, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 02/01/2024 23:24, tTh wrote:
>>> On 1/2/24 21:24, Bart wrote:
>>>>
>>>> You missed my point. Take a tiny feature like being able to easily get
>>>> the size of a fixed-length array. You commonly see macro like this:
>>>>
>>>> #define LENGTH(a) (sizeof(a)/size(a[0]))
>>>
>>> And why is that bad? That's a real question.
>>
>> Where do I start?
>>
>> * Why is it necessary for a million programmers to each come up with
>> their own solutions for something so basic? Eg. they will all use
>> diferent names.
>
> Why is it necessary to exaggerate?
How do you know whether I'm exaggerating or not? There have surely been
many millions of people who've programmed in C over the years.
And a large proportion may have needed the length of an array whose
dimensions are not set by a constant, but by the number of data elements
provided.
(Even in the former case, if you have int A[N] and B[N], I think it is
better to have 'LENGTH(A)' within the subsequent code, rather than a
bare 'N' which could mean anything: is it the length or A, B, or does it
mean N by itself? What happens if you change it to A[M]?)
So there could well have been million people who have created such a
macro, or at least, have had to do it a million times in all.
And if not, the rest would have to write code like this:
> static const size_t PENTIUM_MSR_PT_CNT =
> sizeof(pentium_msr_passthrough) / sizeof(pentium_msr_passthrough[0]);
If you have two similar-sounding arrays, it is easy to mix them up.
Or, somebody reading this code will have to double-check it, to ensure
tha names are identical, to be sure that it /is/ the idiom to get an
array length.
With my suggested feature, and in my style, it would look like this:
enum {PENTIUM_MSR_PT_CNT = lengthof(pentium_msr_passthru)};
(Although this would limit the number of entries in that array to about
2 billion, which would make for a rather large source file.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-03 20:16 +0100 |
| Message-ID | <un4bq2$3a8kc$1@dont-email.me> |
| In reply to | #379815 |
On 03/01/2024 18:14, Bart wrote: > On 03/01/2024 15:32, Scott Lurndal wrote: >> Bart <bc@freeuk.cm> writes: >>> On 02/01/2024 23:24, tTh wrote: >>>> On 1/2/24 21:24, Bart wrote: >>>>> >>>>> You missed my point. Take a tiny feature like being able to easily get >>>>> the size of a fixed-length array. You commonly see macro like this: >>>>> >>>>> #define LENGTH(a) (sizeof(a)/size(a[0])) >>>> >>>> And why is that bad? That's a real question. >>> >>> Where do I start? >>> >>> * Why is it necessary for a million programmers to each come up with >>> their own solutions for something so basic? Eg. they will all use >>> diferent names. >> >> Why is it necessary to exaggerate? > > How do you know whether I'm exaggerating or not? There have surely been > many millions of people who've programmed in C over the years. > And how many of them define or use such a macro? Some, certainly, but not all. I can't say I have ever had one in my code as far as I remember. Occasionally I find it convenient to calculate the size of an existing array, but I'll just write it manually as an expression (like Scott seems to do). Generally if I need the size of an array, I already know it - I can use the same "no_of_samples" (or whatever) constant I used when defining the array in the first place. > And a large proportion may have needed the length of an array whose > dimensions are not set by a constant, but by the number of data elements > provided. I have no basis to guess whether this proportion is large or small. I don't imagine you do either. > > (Even in the former case, if you have int A[N] and B[N], I think it is > better to have 'LENGTH(A)' within the subsequent code, rather than a > bare 'N' which could mean anything: is it the length or A, B, or does it > mean N by itself? What happens if you change it to A[M]?) The trick is not to use single letter identifiers when you want their meaning to be clear. I would not object to there being a standard C macro for finding the size of an array. But I think it would be out of character for the standard library. It would make more sense if the language had more support for arrays and allowing them as values, parameters, and in expressions - then a standard "size" feature would be expected.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-03 19:57 +0000 |
| Message-ID | <20240103114626.282@kylheku.com> |
| In reply to | #379817 |
On 2024-01-03, David Brown <david.brown@hesbynett.no> wrote: > On 03/01/2024 18:14, Bart wrote: >> On 03/01/2024 15:32, Scott Lurndal wrote: >>> Bart <bc@freeuk.cm> writes: >>>> On 02/01/2024 23:24, tTh wrote: >>>>> On 1/2/24 21:24, Bart wrote: >>>>>> >>>>>> You missed my point. Take a tiny feature like being able to easily get >>>>>> the size of a fixed-length array. You commonly see macro like this: >>>>>> >>>>>> #define LENGTH(a) (sizeof(a)/size(a[0])) >>>>> >>>>> And why is that bad? That's a real question. >>>> >>>> Where do I start? >>>> >>>> * Why is it necessary for a million programmers to each come up with >>>> their own solutions for something so basic? Eg. they will all use >>>> diferent names. >>> >>> Why is it necessary to exaggerate? >> >> How do you know whether I'm exaggerating or not? There have surely been >> many millions of people who've programmed in C over the years. >> > > And how many of them define or use such a macro? Some, certainly, but > not all. I've seen it a lot. If it didn't have issues, it would be an excellent inclusion in <stddef.h>, along with offsetof(type, member) and such. Macros with issues should not be standardized though. For instance min and max macros appear regularly in C programs, but feature multiple argument evaluation. For these kinds of things, it's better to wait until the language develops a good solution. min and max want to be type-generic inline functions. I think that this is doable in C with _Generic. In the April 2023 draft, I don't see any min functions other than fminf, fmin and fminl, which are float, double and long double. No generic min and max are mentioned for <tgmath.h> There are probably too many combinations to handle; you need two levels of _Generic selection, each switching on a number of integer and floating-point types. (There being reams and reams of templates doesn't stop C++, though.) For counting the elements in an array, we really want a sizeof-like keyword, which takes a parenthesized type or expression. That expression is constrained to be of array type. (Might it be possible with _Generic to detect that we have an operand which is an "array of anything"? I'm guessing not.) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-04 09:46 +0100 |
| Message-ID | <un5r9o$3jivl$1@dont-email.me> |
| In reply to | #379819 |
On 03/01/2024 20:57, Kaz Kylheku wrote: > On 2024-01-03, David Brown <david.brown@hesbynett.no> wrote: >> On 03/01/2024 18:14, Bart wrote: >>> On 03/01/2024 15:32, Scott Lurndal wrote: >>>> Bart <bc@freeuk.cm> writes: >>>>> On 02/01/2024 23:24, tTh wrote: >>>>>> On 1/2/24 21:24, Bart wrote: >>>>>>> >>>>>>> You missed my point. Take a tiny feature like being able to easily get >>>>>>> the size of a fixed-length array. You commonly see macro like this: >>>>>>> >>>>>>> #define LENGTH(a) (sizeof(a)/size(a[0])) >>>>>> >>>>>> And why is that bad? That's a real question. >>>>> >>>>> Where do I start? >>>>> >>>>> * Why is it necessary for a million programmers to each come up with >>>>> their own solutions for something so basic? Eg. they will all use >>>>> diferent names. >>>> >>>> Why is it necessary to exaggerate? >>> >>> How do you know whether I'm exaggerating or not? There have surely been >>> many millions of people who've programmed in C over the years. >>> >> >> And how many of them define or use such a macro? Some, certainly, but >> not all. > > I've seen it a lot. If it didn't have issues, it would be an excellent > inclusion in <stddef.h>, along with offsetof(type, member) and such. > > Macros with issues should not be standardized though. For instance min > and max macros appear regularly in C programs, but feature multiple > argument evaluation. Arguably the "array size" macros /do/ have issues. Either they are too easy to use accidentally with pointers instead of arrays, or they cause compile-time errors for arrays of size one (due to protection against use with pointers), or they rely on compiler extensions to protect against use on pointers. In one way, that would make it a better choice to have "array_size" in the standard - the standard could simply require that applying "array_size" to a pointer is a constraint error, and it's up to the implementation to figure out what compiler magic is needed to make that work. (The "offsetof" macro is similar - it can't be implemented in completely portable, compliant and fully defined behaviour C code.) However, I think it is all too late for that. It certainly can't be added to <stddef.h> or <stdlib.h> - what would you call it without conflicting with existing names in existing code? You'd have to put it in its own header, and it would all be a huge amount of work and fuss for something that no one would ever use - everyone who wants such a macro can write one faster themselves than it takes to type "#include <stdarraysize.h>". > > For these kinds of things, it's better to wait until the language > develops a good solution. min and max want to be type-generic inline > functions. I think that this is doable in C with _Generic. In the > April 2023 draft, I don't see any min functions other than fminf, > fmin and fminl, which are float, double and long double. No generic > min and max are mentioned for <tgmath.h> > > There are probably too many combinations to handle; you need > two levels of _Generic selection, each switching on a number of integer > and floating-point types. (There being reams and reams of templates > doesn't stop C++, though.) > C++ has three major differences for this kind of thing. One is that they have a good namespace for new standard library functions, hugely reducing the risk and cost of adding functions. They have arrays as "real" types - useable as values and with strong typing, eliminating the complication of decaying to pointers to the first element. (If you are programming in C++ and are working with fixed size arrays, std::array<> is often a better choice than C-style arrays. And if you are using dynamic arrays, std::vector<> is probably best.) And C++ already has an advanced template system that is far beyond what you can do with C11's _Generic. So I think you are partially right - I agree it is better not to try to have this kind of thing in the standard library without better language support for metaprogramming and for more solid arrays, but I don't think C will or should gain such features. I think C should be considered "mostly complete" - some improvements are helpful, but not major language changes. The whole point of C is its stability as a language, and if a programmer wants more, it's better to choose a different language such as C++ or one of the "better than C but less complicated than C++" options such as D or Rust. > For counting the elements in an array, we really want a sizeof-like > keyword, which takes a parenthesized type or expression. That expression > is constrained to be of array type. > > (Might it be possible with _Generic to detect that we have an operand > which is an "array of anything"? I'm guessing not.) >
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-04 18:57 +0000 |
| Message-ID | <20240104105102.429@kylheku.com> |
| In reply to | #379825 |
On 2024-01-04, David Brown <david.brown@hesbynett.no> wrote: > However, I think it is all too late for that. It certainly can't be > added to <stddef.h> or <stdlib.h> - what would you call it without > conflicting with existing names in existing code? I would call it elems or something, and hide the identifier unless a new dialect of C is being used. E.g. in the case of gcc, it would not be revealed in <stddef.h> if only -std=c23 is in effect; a newer dialect selection would be required. The standard headers have been getting new identifiers, right? Like many new functions in <math.h>. Those are functions which have linkage, which presents an implementation challenge on top of the declarations in the header being easy to hide. A size operator for arrays doesn't have linkage to worry about. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-03 23:48 +0000 |
| Message-ID | <un4ro2$3ce1u$1@dont-email.me> |
| In reply to | #379817 |
On 03/01/2024 19:16, David Brown wrote:
> On 03/01/2024 18:14, Bart wrote:
>> How do you know whether I'm exaggerating or not? There have surely
>> been many millions of people who've programmed in C over the years.
>>
>
> And how many of them define or use such a macro? Some, certainly, but
> not all. I can't say I have ever had one in my code as far as I
> remember. Occasionally I find it convenient to calculate the size of an
> existing array, but I'll just write it manually as an expression (like
> Scott seems to do).
So writing the same long identifier twice? And hoping there's no typo in
one? Because sizeof(A)/sizeof(B[0]) would be legal code when both A and
B are arrays.
(I already know your counter-argument: what stops someone writing
LENGTH(B) instead of LENGTH(A) anyway. Well, writing it twice gives two
opportunities to get it wrong!)
> Generally if I need the size of an array, I already
> know it - I can use the same "no_of_samples" (or whatever) constant I
> used when defining the array in the first place.
This is my A/B/N argument below. Maybe 'no_of_samples' is used as the
dimension for more than one array.
>> And a large proportion may have needed the length of an array whose
>> dimensions are not set by a constant, but by the number of data
>> elements provided.
>
> I have no basis to guess whether this proportion is large or small. I
> don't imagine you do either.
Well, here is an extract from sqlite3.c:
/*
** A convenience macro that returns the number of elements in
** an array.
*/
#define ArraySize(X) ((int)(sizeof(X)/sizeof(X[0])))
They considered it worth having. Here's another from SDL2:
/**
* The number of elements in an array.
*/
#define SDL_arraysize(array) (sizeof(array)/sizeof(array[0]))
I didn't see one in TCC sources; they have stuff like this instead:
for(i = 0; i < sizeof(reg_saved)/sizeof(reg_saved[0]); i++) {
A loop that I would write (in 1-based form), as:
for i to reg_saved.len do
I write 'i' once, not three times; and 'reg_saved' once, not twice.
My view remains that C could do with a standardised macro, or a built-in
feature like the lengthof() extension I demonstrated.
>> (Even in the former case, if you have int A[N] and B[N], I think it is
>> better to have 'LENGTH(A)' within the subsequent code, rather than a
>> bare 'N' which could mean anything: is it the length or A, B, or does
>> it mean N by itself? What happens if you change it to A[M]?)
>
> The trick is not to use single letter identifiers when you want their
> meaning to be clear.
That doesn't affect my point. You still can't tell whether N or anything
longer refers to the length of the first or second array. Including the
name of the thing you're taking the length of is useful redundancy.
> I would not object to there being a standard C macro for finding the
> size of an array. But I think it would be out of character for the
> standard library.
It's in character for C to define a chunk of the language via the
standard library. That doesn't appeal to me, it is very crude aspect of
the language, and also makes basic language features optional: they
don't exist until specifically enabled.
> It would make more sense if the language had more
> support for arrays and allowing them as values, parameters, and in
> expressions - then a standard "size" feature would be expected.
I can't see how that effects anything. If you have:
T A[] = {...};
then it always makes sense to have a direct way of getting the number of
elements in A without resorting to those measures demonstrated above.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-04 01:57 +0000 |
| Message-ID | <mgolN.15004$SyNd.1220@fx33.iad> |
| In reply to | #379822 |
Bart <bc@freeuk.cm> writes: >On 03/01/2024 19:16, David Brown wrote: >> On 03/01/2024 18:14, Bart wrote: > >>> How do you know whether I'm exaggerating or not? There have surely >>> been many millions of people who've programmed in C over the years. >>> >> >> And how many of them define or use such a macro? Some, certainly, but >> not all. I can't say I have ever had one in my code as far as I >> remember. Occasionally I find it convenient to calculate the size of an >> existing array, but I'll just write it manually as an expression (like >> Scott seems to do). > >So writing the same long identifier twice? Yes. Good editors mean you don't need to type it twice (ywllp). >And hoping there's no typo in one? If there's a typo, the compiler will note it and I'll fix it. But, see above. > Because sizeof(A)/sizeof(B[0]) would be legal code when both A and >B are arrays. Good thing I don't use single letter identifiers.
[toc] | [prev] | [next] | [standalone]
Page 5 of 34 — ← Prev page 1 … 3 4 [5] 6 7 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web