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 29 of 34 — ← Prev page 1 … 27 28 [29] 30 31 … 34 Next page →
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 12:14 +0000 |
| Message-ID | <une4j0$12mv0$1@dont-email.me> |
| In reply to | #379902 |
On 07/01/2024 02:14, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 01:26:29 +0000, Bart wrote:
>
>> And then what? LIBFFI is still hard to use.
>
> Using Python’s ctypes module, which is basically built on top of libffi, I
> have not found to be that hard at all.
>
> Looking at the sizes of those particular Python wrappers I mentioned:
>
> Cairo graphics <https://gitlab.com/ldo/qahirah> -- 8500 lines
> D-bus <https://gitlab.com/ldo/dbussy/> -- 11,000 lines
> inotify <https://gitlab.com/ldo/inotipy> -- under 600 lines
While I have my own C alternative language, I also have my own Python
alternative language, although it is smaller, lower level and less
dynamic. On this scale:
C-1---2---------Python
my languages might occupy positions 1 and 2.
> Using Python’s ctypes module, which is basically built on top of
libffi, I
> have not found to be that hard at all.
OK, so you're using:
* A LIBFFI module that someone one else has written
* A language (Python) that someone else has implemented (and
originally, someone else has designed)
* An extension (Ctypes) that is already done by somebody
* A set of FFI bindings to some external library that someone has
already taken the trouble to create
* On top of that, you're probably using a C compiler that someone
else has implemented (used to build LIBFFI etc and which has
likely been used to build Python)
* Plus a bunch of dependencies that others have taken care of (build
systems etc)
So it is not surprising that:
> I have not found to be that hard at all.
Is there much left for you to do?
I find it a little bit harder because I design and implement my own
languages, I need to create my own bindings to libraries, and do all
that without any dependencies other than those libraries I'm trying to use.
And yet my dynamic language's FFI is much easier to use than most
scripting languages. The FFI is built in as is support the low-level
types needed. No extension module is needed.
I can do this from interpreted, dynamic code (the printf is predefined
but I'm showing here how it is predefined:
importdll msvcrt =
func printf(stringz, ...)int32
end
printf("Hello, World!\n")
(When I used to run it on Linux, the 'msvcrt' library was mapped
internally to 'libc.so.6').
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-07 19:29 +0000 |
| Message-ID | <uneu26$168e6$2@dont-email.me> |
| In reply to | #379909 |
On Sun, 7 Jan 2024 12:14:24 +0000, Bart wrote:
> Is there much left for you to do?
Yes. Make it work as though it were written for Python programmers.
For example, the Cairo graphics API requires you to pass X- and Y-
coordinates as separate arguments to every function. I wrap them up into a
single “Vector” type, with its own arithmetic operators. For example,
compare what you would have to do in C:
x0 = 0;
y0 = scope_radius;
x1 = x0 * cos(- trace_width_angle) - y0 * sin(- trace_width_angle);
y1 = x0 * sin(- trace_width_angle) + y0 * cos(- trace_width_angle);
cairo_line_to(ctx, x1, y1);
with what my Python wrapper allows:
ctx.line_to(Vector(0, - scope_radius).rotate(- trace_width_angle))
I had to write the code to do that.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 22:41 +0000 |
| Message-ID | <unf9a6$17v0c$1@dont-email.me> |
| In reply to | #379913 |
On 07/01/2024 19:29, Lawrence D'Oliveiro wrote:
> On Sun, 7 Jan 2024 12:14:24 +0000, Bart wrote:
>
>> Is there much left for you to do?
>
> Yes. Make it work as though it were written for Python programmers.
>
> For example, the Cairo graphics API requires you to pass X- and Y-
> coordinates as separate arguments to every function. I wrap them up into a
> single “Vector” type, with its own arithmetic operators. For example,
> compare what you would have to do in C:
>
> x0 = 0;
> y0 = scope_radius;
> x1 = x0 * cos(- trace_width_angle) - y0 * sin(- trace_width_angle);
> y1 = x0 * sin(- trace_width_angle) + y0 * cos(- trace_width_angle);
> cairo_line_to(ctx, x1, y1);
>
> with what my Python wrapper allows:
>
> ctx.line_to(Vector(0, - scope_radius).rotate(- trace_width_angle))
>
> I had to write the code to do that.
I was interested in the FFI used by CPython as I'd never seen it in
action. The setup, as used in your link, is something like this:
cairo = ct.cdll.LoadLibrary(LIBNAME["cairo"]) # LIBNAME is a dict
...
cairo.cairo_line_to.argtypes = (ct.c_void_p, ct.c_double, ct.c_double)
cairo.cairo_line_to.restype = None
...
c_double etc are from 'ctypes', and 'ct' is an alias for that module.
So it's all done with libraries, classes, tuples and attributes.
But so far, no need for LIBFFI; that's only needed when you call that
function.
In my dynamic language, the equivalent set up code is:
type cairo_t = ref void # I guess cairo_t is opaque
importdll cairo = # don't know the exact dll name
...
proc cairo_line_to(cairo_t ctx, r64 x, y)
...
end
This is called as 'cairo_line_to(...)'. Actually the syntax used in this
example is exactly the same as my static language.
I'm using parameter names so that, with more elaborate functions, I can
use keyword arguments. I can also define default values so that not all
arguments need be supplied.
In the dynamic version, both DLL and individual functions are loaded
on-demand; that is, the first time a library or function is needed. The
code runs even without the DLL if I don't call any functions from it.
---
So, this is what /I/ do, provide simple, easy-to-use features that other
languages make a bit of a meal over.
From your library:
def line_to(self, p) :
...
#end line_to
I see you have the same opinion of Python block syntax as I do. Nim does
the same thing; I had to add exactly those #end comments as I kept
getting things lined up wrong.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-01-07 23:27 +0000 |
| Message-ID | <unfc0n$188hr$2@dont-email.me> |
| In reply to | #379914 |
On Sun, 7 Jan 2024 22:41:11 +0000, Bart wrote: > I'm using parameter names so that, with more elaborate functions, I can > use keyword arguments. I can also define default values so that not all > arguments need be supplied. Python has all that as standard. But you can’t define custom overloads for operators as in Python, can you? That’s important to the definitions of my “Vector” and “Matrix” types, just for example. > importdll cairo = # don't know the exact dll name On Linux, that‘s “libcairo.so.2”. Note the “.2” on the end. That gets incremented if there are any incompatible ABI changes made. Windows seems to have no mechanism for this. > From your library: > > def line_to(self, p) : > ... > #end line_to > > I see you have the same opinion of Python block syntax as I do. I have custom Emacs commands to jump between lines with the same indentation level. That lets me move quickly between the beginning and ending of a nested block. I also have commands to jump to the beginning/ end of the next outer indentation level.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-06 15:43 +0000 |
| Message-ID | <unbse5$lk55$1@dont-email.me> |
| In reply to | #379883 |
On 06/01/2024 14:28, David Brown wrote:
> On 06/01/2024 13:53, Bart wrote:
>> On 06/01/2024 09:09, David Brown wrote:
>>> On 05/01/2024 23:19, Bart wrote:
>>>> On 05/01/2024 14:05, David Brown wrote:
>>>>> On 05/01/2024 02:53, Bart wrote:
>>>>
>>>>>> It doesn't need to take a heavy-handed approach like C++ or Python.
>>>>>>
>>>>>
>>>>> One option for a useful array length operator/function/macro is a
>>>>> simple and limited feature that works for arrays of known size and
>>>>> gives a hard (compile-time) error when the size is not known. The
>>>>> one you have in your own language covers most of that, except for
>>>>> the insanity of evaluating to 0 when given a pointer/reference to
>>>>> an "unbounded" array.
>>>>
>>>> It gives zero because that is actually the compile-time type of the
>>>> array. But it is low priority because it is never used that way.
>>>>
>>>
>>> That's the kind of potentially confusing short-cut you can make when
>>> only you ever use the language.
>>
>> I spent 10 mins trying to fix this today. So that '.len' on bounds
>> specified as `[]` rather than `[0]`, and not later set by init data,
>> would be an error.
>>
>> Then I got stuck on examples like '[]int a = ()' and realised it's
>> tricky. And then I thought, why the hell am I doing this? A language
>> I've already used for a million lines of code.
>>
>
> I have no idea why you are doing this. I have no idea why you thought
> it was a good idea to make your own personal language and write a
> million lines that no one can ever use again, or work with, change,
> re-use, maintain or update.
It started as an in-house language. It was used for real work, real
programs. The products I made with it generated some $1m a year of
business and created work for quite a few people. 1000s of customers
benefited from those products for their own endeavours. And I managed to
retire at age 42.
Those are some reasons.
> I have no idea why you hate C, why you
> obsess about a language you hate and why you rave about your language
> that no one else uses and no one else cares about in a newsgroup for C.
> I have no idea why you continue to think that your language is God's
> gift to programming and that everyone else, the world over, is crazy to
> imagine there are any reasons to do something differently from the way
> you do things in your language.
>
> Yes, "why?" is a good question.
Why? You pick on some relatively minor issue in my language, of which C
has in spades.
I list some aspects of working with arrays which I do better than C, to
put into perspective why I considered that low priority.
And you choose to go on the attack.
That no one uses my language is irrelevant. The ideas would stand by
themselves, even if never implemented. But being used in a real, proven
product should lend more credence. Be funny if you took vapourware more
seriously.
Where are the systems languages from 70s/80s that did it properly? There
aren't any; Unix put paid to that by inflicting its shitty language on
everybody and everything.
I picked on the sizeof thing for arrays as a simple example of C's
macros used to paper over deficiences in the core language. You and
others say it's no big deal.
Well, dozens of other languages do do it properly, eg. using len(A), not
just mine. Mine just demonstrates its use in a language of similar level
and scale.
I think you're just cross that my table wipes the floor with C and so
want to piss all over my own efforts.
--------
BTW here is my original comment about sizeof/sizeof:
BC to DB:
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's a good job I went with LENGTH and not GETBIT. I use as A.[n] for
both GETBIT and SETBIT, and you would have gotten even angrier. How dare
somebody not only come up with some decent ideas for a systems language,
but who actually has the gall to go and implement them.
You are welcome to 'A.[i]'; I think it would have been a far more
interesting addition to new C that whatever it was that did go in. And
easy to implement to boot; with I believe no clashes with current syntax.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-01-07 03:32 +0000 |
| Message-ID | <20240106193126.377@kylheku.com> |
| In reply to | #379880 |
On 2024-01-06, Bart <bc@freeuk.cm> wrote: > Then I got stuck on examples like '[]int a = ()' and realised it's > tricky. And then I thought, why the hell am I doing this? A language > I've already used for a million lines of code. That exact reasoning can be used to reject new features from C, like an operator for the number of elements in an array. People have written billions of lines of C without it! -- 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-07 11:37 +0000 |
| Message-ID | <une2d7$12d72$1@dont-email.me> |
| In reply to | #379907 |
On 07/01/2024 03:32, Kaz Kylheku wrote:
> On 2024-01-06, Bart <bc@freeuk.cm> wrote:
>> Then I got stuck on examples like '[]int a = ()' and realised it's
>> tricky. And then I thought, why the hell am I doing this? A language
>> I've already used for a million lines of code.
>
> That exact reasoning can be used to reject new features from C,
> like an operator for the number of elements in an array.
>
> People have written billions of lines of C without it!
>
That's a feature for which there is a need.
The other is requiring a diagnostic, somewhat less useful if you just
want to loop over an array without it looking like a dog's dinner.
So, C has distinct concepts of 'zero-length' array and 'unbounded
array', so that sizeof/sizeof on the latter generates a diagnostic.
Great. But you don't get one here:
int a;
int* p=&a;
printf("%zu\n", sizeof(p)/sizeof(p[0]));
'p' is neither a zero-length nor unbounded array, but the array-length
idiom still works. This program will likely print '2' on 64-bit machines.
If I try the same thing:
int a
ref int p := &a
println p.len
it gives an error. But I can also get C's behaviour if I really wanted
to do that:
println p.bytes/p^.bytes
This shows '1' (int is 64 bits).
There /is/ a significant difference between sizeof and lengthof;
emulating the latter with sizeof doesn't really cut it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-07 14:41 -0800 |
| Message-ID | <87wmskrckc.fsf@nosuchdomain.example.com> |
| In reply to | #379908 |
Bart <bc@freeuk.cm> writes:
> On 07/01/2024 03:32, Kaz Kylheku wrote:
>> On 2024-01-06, Bart <bc@freeuk.cm> wrote:
>>> Then I got stuck on examples like '[]int a = ()' and realised it's
>>> tricky. And then I thought, why the hell am I doing this? A language
>>> I've already used for a million lines of code.
>> That exact reasoning can be used to reject new features from C,
>> like an operator for the number of elements in an array.
>> People have written billions of lines of C without it!
>
> That's a feature for which there is a need.
Not really. It would be convenient. It's not absolutely *needed*, as
demonstrated by the fact that "People have written billions of lines of
C without it!".
> The other is requiring a diagnostic, somewhat less useful if you just
> want to loop over an array without it looking like a dog's dinner.
>
> So, C has distinct concepts of 'zero-length' array and 'unbounded
> array', so that sizeof/sizeof on the latter generates a diagnostic.
No, it doesn't. C doesn't have zero-length arrays. A fixed-length
array with a length of 0:
int arr[0];
is a constraint violation. A VLA with a length of 0:
int n = 0;
int vla[n];
has undefined behavior. (You can probably find compilers that support
either or both as an extension.)
I don't know what you mean by "unbounded array".
Every array object has a length that's determined no later than when the
object's lifetime begins, and that cannot be changed during the object's
lifetime. All C array objects are bounded.
> so that sizeof/sizeof on the latter generates a diagnostic.
>
> Great. But you don't get one here:
>
> int a;
> int* p=&a;
>
> printf("%zu\n", sizeof(p)/sizeof(p[0]));
>
> 'p' is neither a zero-length nor unbounded array, but the array-length
> idiom still works. This program will likely print '2' on 64-bit
> machines.
Yes, we've discussed that issue repeatedly in this thread.
[information about your own language snipped]
Yes, some languages other than C have better support for this than C
does.
> There /is/ a significant difference between sizeof and lengthof;
> emulating the latter with sizeof doesn't really cut it.
#define LENGTHOF(arr) (sizeof (arr) / sizeof (arr)[0] )
This works perfectly well if the programmer ensures that it's applied
only to an array expression, typically the name of an array object.
I've used it myself, either via a similar macro or directly, and never
had a problem with it.
Yes, it fails to diagnose an error and gives a bogus result if you apply
it to a pointer object or expression. This issue has been repeatedly
acknowledged in this thread, including discussions of how to fix it if
you can use a gcc-specific extension. What more is there to say about
it?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-07 22:54 +0000 |
| Message-ID | <unfa3v$1822c$1@dont-email.me> |
| In reply to | #379915 |
On 07/01/2024 22:41, Keith Thompson wrote:
> Bart <bc@freeuk.cm> writes:
>> So, C has distinct concepts of 'zero-length' array and 'unbounded
>> array', so that sizeof/sizeof on the latter generates a diagnostic.
> No, it doesn't. C doesn't have zero-length arrays. A fixed-length
> array with a length of 0:
> int arr[0];
> is a constraint violation.
So you can't have an array with an empty initialiser list either?
I must say you have to try quite hard to get a diagnostic for those!
So what happens if you have a generated data block for example,
containing N items; it only works when N is at least 1? What are you
supposed to do when N is zero?
It sounds quite a limitation.
> I don't know what you mean by "unbounded array".
One without a bound specified? C might call it 'incomplete', even though
the syntax is common; this is one example of many:
void F(int A[]) {}
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-07 16:06 -0800 |
| Message-ID | <87o7dwr8nn.fsf@nosuchdomain.example.com> |
| In reply to | #379916 |
Bart <bc@freeuk.cm> writes:
> On 07/01/2024 22:41, Keith Thompson wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> So, C has distinct concepts of 'zero-length' array and 'unbounded
>>> array', so that sizeof/sizeof on the latter generates a diagnostic.
>
>> No, it doesn't. C doesn't have zero-length arrays. A fixed-length
>> array with a length of 0:
>> int arr[0];
>> is a constraint violation.
>
> So you can't have an array with an empty initialiser list either?
An empty initializer list is a syntax error. (It will be allowed in
C23.)
> I must say you have to try quite hard to get a diagnostic for those!
Why must you say that when it isn't true?
$ cat c.c
int arr[] = {};
$ gcc -c c.c
$ gcc -std=c17 -pedantic c.c
c.c:1:13: warning: ISO C forbids empty initializer braces [-Wpedantic]
1 | int arr[] = {};
| ^
c.c:1:5: error: zero or negative size array ‘arr’
1 | int arr[] = {};
| ^~~
$
> So what happens if you have a generated data block for example,
> containing N items; it only works when N is at least 1?
Yes.
> What are you
> supposed to do when N is zero?
Something else, I suppose.
> It sounds quite a limitation.
Since I have no agenda here, I won't try to quantify how much of a
limitation it is.
>> I don't know what you mean by "unbounded array".
>
> One without a bound specified? C might call it 'incomplete', even
> though the syntax is common; this is one example of many:
>
> void F(int A[]) {}
That's a particularly bad example, since A, being a parameter, is of
pointer type.
int[] is an incomplete type. You can't create objects of incomplete
types, and you can't apply sizeof to incomplete types.
The C standard uses the word "unbounded" a few times, but only in
reference to mathematical functions, not arrays.
Incomplete array types have no particular relationship to VLAs.
When you brought up "unbounded arrays", you seemed to be talking about
array objects whose length can change during their lifetime. C has no
such feature. Do you understand that?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-05 15:54 +0000 |
| Message-ID | <mDVlN.135110$p%Mb.121089@fx15.iad> |
| In reply to | #379851 |
Bart <bc@freeuk.cm> writes: >On 04/01/2024 23:25, Lawrence D'Oliveiro wrote: >> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote: >> >>> For 40 years 99% of my coding has been in a language where you just >>> write: >>> >>> A.len >> >> Better still: >> >> len(A) >> >> which is just a generic wrapper around >> >> A.__len__() >> >> so it will work with your custom object types as well, all they have to do >> is define a method with that name. > >If a language has a built-in The C language doesn't have such a built-in. Any discussion that assumes it does, or will, is pointless.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-05 16:23 +0000 |
| Message-ID | <un9ae2$77ft$1@dont-email.me> |
| In reply to | #379855 |
On 05/01/2024 15:54, Scott Lurndal wrote: > Bart <bc@freeuk.cm> writes: >> On 04/01/2024 23:25, Lawrence D'Oliveiro wrote: >>> On Thu, 4 Jan 2024 22:48:17 +0000, Bart wrote: >>> >>>> For 40 years 99% of my coding has been in a language where you just >>>> write: >>>> >>>> A.len >>> >>> Better still: >>> >>> len(A) >>> >>> which is just a generic wrapper around >>> >>> A.__len__() >>> >>> so it will work with your custom object types as well, all they have to do >>> is define a method with that name. >> >> If a language has a built-in > > The C language doesn't have such a built-in. Any discussion that > assumes it does, or will, is pointless. It could be an extension. I assume none of your code uses extensions to standard C? Not even inline assembly?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-04 09:55 +0100 |
| Message-ID | <un5rpo$3jivl$2@dont-email.me> |
| In reply to | #379822 |
On 04/01/2024 00:48, Bart wrote: > 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. > If you have difficulty typing out the same identifier twice, then you have picked a poor name for the identifier! The whole point of identifiers is to identify things - you give the thing a name, so that you can refer to it later by that same name and know you are referring to the same thing. If find this difficult when using the same array identifier twice in one expression, then you have vastly bigger problems with your coding than getting the size of an array. > (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!) No, that was never in my thoughts as a counter-argument. > >> 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. Yes, maybe it is. But I know the size of the arrays I use. If I don't know, I look at the definition to see. I don't code blindly. > >>> 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: I didn't write sqlite3.c. I am not responsible for the choices of identifiers, or coding style, or macro usage, or anything else in it. I am telling you why /I/ don't need or use any kind of "array_size" macro. Other people may write their code differently.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-04 12:15 +0000 |
| Message-ID | <un67g4$3l74d$1@dont-email.me> |
| In reply to | #379826 |
On 04/01/2024 08:55, David Brown wrote:
> On 04/01/2024 00:48, Bart wrote:
>> 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.
>>
>
> If you have difficulty typing out the same identifier twice, then you
> have picked a poor name for the identifier! The whole point of
> identifiers is to identify things - you give the thing a name, so that
> you can refer to it later by that same name and know you are referring
> to the same thing. If find this difficult when using the same array
> identifier twice in one expression, then you have vastly bigger problems
> with your coding than getting the size of an array.
You can make typos. You can accidentally use the name of some other
similarly named but unrelated variable.
You really can't understand that the opportunities for such errors
increases with the amount of code you have to write? As well as the
amount of obscuring clutter?
It's not just writing two long identifiers instead of one; here those
additionally have to match.
> Yes, maybe it is. But I know the size of the arrays I use. If I don't
> know, I look at the definition to see. I don't code blindly.
You have this (and please don't complain about these terse names; a real
program will be much larger, much busier, and have much longer names):
enum {N = 10;}
int A[N];
int B[N];
int C[N];
for (i = 0; i<N; ++N)
... Do something with A ...
for (i = 0; i<N; ++N)
... Do something with B ...
(I will leave the typos I've just noticed. Bloody stupid C for loops...)
Later I change A[N] to be A[M] as I said a few posts ago. Now you have
to go through the program looking for things that reference the length of A.
But you only have N; you can't tell from that itself whether it I
specifically used as the length of A or not. The job is harder. Now
consider this version:
for (i = 0; i<LENGTH(A); ++i)
... Do something with A ...
for (i = 0; i<LENGTH(B); ++i)
... Do something with B ...
Which version will be easier to update? (Hint: this one doesn't need any
changes.)
>> Well, here is an extract from sqlite3.c:
>
> I didn't write sqlite3.c. I am not responsible for the choices of
> identifiers, or coding style, or macro usage, or anything else in it. I
> am telling you why /I/ don't need or use any kind of "array_size" macro.
> Other people may write their code differently.
So in you code, if I see:
sizeof(expr1)/sizeof(expr2)
what I am supposed to deduce from that? That it /might/ be an idiom for
getting the number of elements in array? Then it might involving looking
in more detail to see that expr2 is really just expr1[0].
On the other hand, if I see:
ArraySize(expr)
then you are expressing what your intentions are more clearly. Moreover,
with that term now being more compact, I can concentrate more on what
goes before and after it.
BTW here is anoher macro, this time from a file called gcc.c (an old
amalgamation):
#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
*Everybody* is at it, but that doesn't count because /you/ don't do it?
It is used like this:
for (i = 0; i < ARRAY_SIZE (conversion_tab); i++)
if (sysctl (mib, ARRAY_SIZE (mib), &physmem, &len, NULL, 0) == 0
b < (operator_array + ARRAY_SIZE (operator_array));
size_t n = ARRAY_SIZE (builtin_array);
which would otherwise look like so:
for (i = 0; i < sizeof(conversion_tab)/sizeof(conversion_tab); i++)
if (sysctl (mib, sizeof(mib)/sizeof(mib[0]), &physmem, &len, NULL,
0) == 0
b < (operator_array +
sizeof(operator_array)/sizeof(operator_array)[0]);
size_t n = sizeof(builtin_array)/sizeof(builtin_array[0]);
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-04 15:29 +0100 |
| Message-ID | <un6fcd$3m9rm$1@dont-email.me> |
| In reply to | #379828 |
On 04/01/2024 13:15, Bart wrote:
> On 04/01/2024 08:55, David Brown wrote:
>> On 04/01/2024 00:48, Bart wrote:
>>> 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.
>>>
>>
>> If you have difficulty typing out the same identifier twice, then you
>> have picked a poor name for the identifier! The whole point of
>> identifiers is to identify things - you give the thing a name, so that
>> you can refer to it later by that same name and know you are referring
>> to the same thing. If find this difficult when using the same array
>> identifier twice in one expression, then you have vastly bigger
>> problems with your coding than getting the size of an array.
>
> You can make typos. You can accidentally use the name of some other
> similarly named but unrelated variable.
>
> You really can't understand that the opportunities for such errors
> increases with the amount of code you have to write? As well as the
> amount of obscuring clutter?
>
> It's not just writing two long identifiers instead of one; here those
> additionally have to match.
>
>
>> Yes, maybe it is. But I know the size of the arrays I use. If I
>> don't know, I look at the definition to see. I don't code blindly.
>
> You have this (and please don't complain about these terse names; a real
> program will be much larger, much busier, and have much longer names):
>
> enum {N = 10;}
> int A[N];
> int B[N];
> int C[N];
>
> for (i = 0; i<N; ++N)
> ... Do something with A ...
>
> for (i = 0; i<N; ++N)
> ... Do something with B ...
>
> (I will leave the typos I've just noticed. Bloody stupid C for loops...)
>
> Later I change A[N] to be A[M] as I said a few posts ago. Now you have
> to go through the program looking for things that reference the length
> of A.
>
> But you only have N; you can't tell from that itself whether it I
> specifically used as the length of A or not. The job is harder. Now
> consider this version:
>
> for (i = 0; i<LENGTH(A); ++i)
> ... Do something with A ...
>
> for (i = 0; i<LENGTH(B); ++i)
> ... Do something with B ...
>
> Which version will be easier to update? (Hint: this one doesn't need any
> changes.)
>
That is not a problem I would come across in my code. If, for example,
B and C hang together tightly while A might be different, then I would
be defining them as :
enum { N_A = 10, N_BC = 10 };
int A[N_A];
int B[N_BC];
int C[N_BC];
I wouldn't use the same size constant for inherently separate things
simply because they happened to have the same number of items!
And if I later decided that B and C did not belong tightly coupled after
all, I'd change it to:
enum { N_A = 10, N_B = 10, N_C = 10 };
int A[N_A];
int B[N_B];
int C[N_C];
I would expect to have to change the usage of the arrays in conjunction
with the decoupling change, so changing the later for-loops is needed
anyway. And if I forgot, the compiler would remind me when the use of
N_BC fails to compile - forcing me to double-check the usage. I'd
rather be forced to change the later loops, than have them compile
silently after such changes, since it is likely that they will need
other modification.
>
>
>>> Well, here is an extract from sqlite3.c:
>>
>> I didn't write sqlite3.c. I am not responsible for the choices of
>> identifiers, or coding style, or macro usage, or anything else in it.
>> I am telling you why /I/ don't need or use any kind of "array_size"
>> macro. Other people may write their code differently.
>
>
> So in you code, if I see:
>
> sizeof(expr1)/sizeof(expr2)
>
> what I am supposed to deduce from that? That it /might/ be an idiom for
> getting the number of elements in array? Then it might involving looking
> in more detail to see that expr2 is really just expr1[0].
>
You are supposed to deduce that I did not write it. I would never use
such bad spacing conventions :-)
But if it is not clear and obvious what is going on, then the code is bad.
> On the other hand, if I see:
>
> ArraySize(expr)
>
> then you are expressing what your intentions are more clearly.
That is assuming you know whether ArraySize returns the number of
elements in the array, or its size in bytes.
But if you prefer a macro like this to alternatives, that's fine. I can
only tell you what /I/ prefer to do.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2024-01-06 05:33 +0100 |
| Message-ID | <unal66$uc4$1@news.gegeweb.eu> |
| In reply to | #379828 |
On 1/4/24 13:15, Bart wrote:
>
> for (i = 0; i<N; ++N)
> ... Do something with A ...
And do nothing for the first element, big win.
--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-03 17:41 +0100 |
| Message-ID | <un42nr$38vqs$1@dont-email.me> |
| In reply to | #379794 |
On 02/01/2024 21:24, 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
> };
> -------
(Why did you change the type from "p_func_t" to "void*" ? Was it just
to annoy myself and other C programmers with a pointless and
constraint-violating cast of a function pointer to "void*" ? Just add a
suitable typedef - "typedef void(*p_func_t)(void);" )
That's a fairly ugly way to express x-macros. It is neater to have the
extractor macro as a parameter to the list macro. Of course, you'd know
that if you read the stack overflow link you gave, since it comes
slightly below the code you copied. But presumably you preferred to use
the ugliest version that you could pretend was hard to understand (it
isn't), rather than using the improved version.
I personally like to use a slightly different syntax, but that's just
detail and style choice.
#define DoStateList(DO) \
DO(state0, func0) /* Comment */ \
DO(state1, func1) \
DO(state2, func2) \
DO(state3, func3) \
#define GetState(state, func) state,
#define GetFunc(state, func) func,
#define Counter(state, func) +1
enum { num_of_states = DoStateList(Counter) };
enum States {
DoStateList(GetState)
};
p_func_t jump_table[] = {
DoStateList(GetFunc)
};
Note that the states can have comments. You do need a backslash at the
end of each line, and that means comments must be /* */ style, not // style.
It is, of course, quite possible to have generic "Get1", "Get2", etc.,
macros rather than "GetState", "GetFunc".
And since we have the x-macro in place, we can use it for more things.
Why manually declare "extern void func0(void);", etc., when you can do
it in two lines for all the functions?
#define DeclareFunc(state, func) extern void func(void);
DoStateList(DeclareFunc)
Maybe you want a switch rather than a jump table - that could give more
inlining opportunities, and is a common choice for the structure of
things like simple VM's and bytecode interpreters:
#define SwitchEntry(state, func) case state : func(); break;
void jump(enum States s) {
switch (s) {
DoStateList(SwitchEntry);
}
}
There are lots of possibilities here. It's not perfect, and some
complex cases might need a bit of testing debugging (godbolt.org with
the "-E" compiler flag is extremely convenient for this), but testing
and debugging is part of a programmer's daily life.
Overall, it's a code generation technique that can be useful whenever
you need repetitive code patterns. It can also be useful for some kinds
of compile-time calculations (such as setting up tables for CRC
functions.) I would not use it when higher level features could do a
better job - if C++ templates and constexpr functions are clearer, I'd
use them. And sometimes they are not enough, or not clear enough, and
I'd make a Python script to generate the C code. But that applies to
everything in programming, really - you should always look for the best
tool for the job.
>
>
> 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
>
That is an very niche and very limited use-case. Did you seriously add
a special feature to your language based on one example in one stack
overflow question? X macros are just an imaginative way to use a
standard feature of C (and C++), giving vastly more flexibility than
your single-use language feature. I have difficulty seeing how it was
worth the effort putting that feature in your tools.
> Notice:
>
> (1) I don't need any of those weird macros.
They are quite simple. You pretend not to understand them, but this is
/not/ hard.
>
> (2) I don't need those backslashes
The backslashes are a minor inconvenience. I'd prefer if they were
unnecessary. It would be nice if C had something like a "#begindef" and
"#enddef" pair for making multi-line macros without backslashes.
>
> (3) I can add comments to any entry in the table.
So can I.
>
> (4) The 'global' attribute means both enumeration names and the array
> are exported to other modules. Doing the same in C is tricky.
It is not tricky in C - if you want the enumerated type to be accessible
from other units, put it in a header. If you want the functions that
are called to be internal to an implementation file and not mentioned in
the header, just have the state names in the header and use token
pasting to make function names automatically - something like
"state0_handler" - in the implementation file. Simple, consistent,
clear, and it is almost impossible to change the states out of sync with
the handlers without leading to a compile-time error. And /that/ is the
main purpose - not reducing typing, or looking neat.
(I do not think C's way of handling import/export of symbols is ideal.
It might be that your language's way is better, in at least some ways.
But since this is C, we do it the C way.)
>
> But I'm wasting my time because you are never going to admit my feature
> is superior to X-macros for this purpose.
It's not. Your feature is fine for a very limited use-case, but it is
not close to the flexibility of x-macros.
Let's try a more advanced example.
#include <stdio.h>
#include <string.h>
#include <stdbool.h>
#define REMOVE_COMMAS_(_1, _2, _3, _4, _5, _6, _7, _8, ...) \
_1 _2 _3 _4 _5 _6 _7 _8
#define REMOVE_COMMAS(...) REMOVE_COMMAS_(__VA_ARGS__, ,,,,,,,,)
#define DoCommandList(DO, P, Pvoid) \
DO(show, "Show item i", (i), P(int, i)) \
DO(run, "Run item i with val x", (i, x), P(int, i), P(double, x)) \
DO(hcf, "Stops the whole system and burns everything", (), Pvoid) \
DO(help, "Shows help for all the commands", (), Pvoid) \
#define DeclareFunc(cmd, help_text, params, ...) \
bool cmd_ ## cmd(__VA_ARGS__);
#define P_declare(type, name) type name
#define Pvoid_declare void
DoCommandList(DeclareFunc, P_declare, Pvoid_declare)
#define ShowHelp(cmd, help_text, params, ...) \
printf(" " #cmd REMOVE_COMMAS(__VA_ARGS__) " - " help_text "\n");
#define P_help(type, name) " " #name "(" #type ")"
#define Pvoid_help
bool cmd_help(void) {
printf("Help: \n");
DoCommandList(ShowHelp, P_help, Pvoid_help)
printf("\n\n");
return true;
}
int get_int_param(void);
double get_double_param(void);
#define RunCommand(cmd, help_text, params, ...) \
if (strcmp(command, #cmd) == 0) { \
REMOVE_COMMAS(__VA_ARGS__) \
return cmd_ ## cmd params; \
}
#define P_run(type, name) type name = get_ ## type ## _param();
#define Pvoid_run
bool dispatch_command(const char * command) {
DoCommandList(RunCommand, P_run, Pvoid_run)
printf("Unknown command - try \"help\"\n");
return false;
}
Now, some of that is messy - no doubts there. Some things could have
been a lot easier if C macros were more powerful, with features such as
recursion or neater handling of variadic packs. Macro names scoped
within functions would also make it better. So there's plenty of room
for a new language to make things better than C.
But what do we get out of this? We have all our commands defined in one
list, with the textual name of the command, the parameters, and a help
text. You can't get things out of sync - if you add a command, or
change parameters, the help function, the declarations, and the
dispatcher all adapt automatically.
You might not think this is a good way to structure your source code.
There are many possibilities, including more manual work, or more
run-time work. You could use an external code generator. You could use
a language with much better reflection capabilities (like Python). But
this is something you can do, today, in plain C, and it shows that
x-macros can do vastly more than declare an enumeration and a table of
pointers.
Now, if your language had powerful reflection and metaprogramming
features, along with compile-time execution, so that this kind of thing
could be done within the language without text-based macros, then I
would happily agree that it has better features. Perhaps the way to do
that would be to integrate your interpreted language in your compiler.
>
> (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.
>
There is a marvellous tool that might help you here - it's called "the
internet". You don't need to figure out the right incantations - all
you need to do is search a little, and learn from other people, and you
will have cases like the first simple usage sorted in minutes. It takes
a bit of imagination, experience and trial and error to "invent"
x-macros, and a lot more to "invent" creative uses of variadic macros.
But no one is asking you to do that - all I am saying is that it is easy
to look at existing code, read some blogs or explanations online, and
understand what it is doing. Then you can adapt it to your own uses if
you want.
I simply don't believe you cannot understand how that first "jump_table"
x-macro example works. It requires nothing more than beginners level C
knowledge to comprehend it, and we both know you are a very intelligent
and experienced programmer. Your attempts at claiming it's all too
difficult for you are, quite frankly, pathetic.
>>> 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.
>
And since this is comp.lang.c, I am showing C code. Code from other
languages can sometimes be interesting for comparison, but that's all.
>>>
>>> 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?
What need is there to add a feature to the language when you can already
handle the situation?
>
> 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.
>
The code written by the authors was :
op_arith(L, l_addi, luai_numadd);
Now, I am not familiar with the Lua source code, but I presume that for
people that are, these identifiers will all make perfect sense and it's
all very simple and clear.
You are looking at this all from completely the wrong viewpoint -
intentionally trying to make it look difficult. It makes no more sense
than taking the binary of a program and looking at all the ones and
zeros and trying to understand how they fit together.
> In particular consider my last comment.
Which one? "This looks fun to try to understand, debug or port" ? The
Lua source code is extremely portable, and I've compiled it on 64-bit
PC's and 16-bit microcontrollers. If anyone wants to understand, debug
or port it, they will do so by looking at the high-level code, and
working on things bit for bit as necessary. They won't expand all the
macros and then go and cry.
Or do you mean the question about why inlined functions were not used?
You'd have to ask the Lua developers about that. It might be a matter
of the code age, or the target C dialect, or concerns about efficiency
on some compilers, or habit, or wanting to use many variables without
passing them as parameters. There could be multiple reasons, and none
of us here are really in the position to answer.
>
>
>> 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.
So the problem is your compiler, not other peoples' code? You think
other people should write their code in a way that makes life as easy as
possible for you, writing your compiler? That's a pretty ass-backwards
attitude you have there. Don't you know the world does not revolve
around you and your personal projects?
>
> 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.
>
I expect you could, yes.
> 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?
>
Oh, I fully appreciate that you don't like macros, or the C
preprocessor, or C in general, or C compilers, or pretty much anything
else that every other programmer works with daily. You are entitled to
your own opinions and tastes.
What I don't accept is your believe that you have a rational
justification for your hatred and prejudice. And in my boundless and
unjustified optimism, I keep thinking that if I can persuade you to
learn a bit, and open your mind a little, then you will have a better
understanding of how the rest of the programming world works.
>
>>> Half my use-cases involve inline assembly.
>>
>> Why can't that be in inlined functions?
>
> That doesn't work in inline assembly.
>
So that's a limitation of your tools.
>> 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;
>
Nor can you write more useful macros.
>
>>> 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.
>
That would be a macro that is relevant to C. Other languages would use
different ways to implement compiler barriers, if they need such things.
(It is, as Chris pointed out, a very weird way to make a compiler
barrier. But that's another matter.)
> 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?
>
As usual, you are blaming C for things relevant to other languages.
> 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.
>
It has plenty to say about the C preprocessor - it fully defines it.
> 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!)
>
So MSVC has a bug. Report it if you like.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.cm> |
|---|---|
| Date | 2024-01-03 21:32 +0000 |
| Message-ID | <un4jpj$3bdrl$1@dont-email.me> |
| In reply to | #379814 |
On 03/01/2024 16:41, David Brown wrote:
> On 02/01/2024 21:24, Bart wrote:
> I personally like to use a slightly different syntax, but that's just
> detail and style choice.
>
>
> #define DoStateList(DO) \
> DO(state0, func0) /* Comment */ \
> DO(state1, func1) \
> DO(state2, func2) \
> DO(state3, func3) \
>
> #define GetState(state, func) state,
> #define GetFunc(state, func) func,
> #define Counter(state, func) +1
>
> enum { num_of_states = DoStateList(Counter) };
>
> enum States {
> DoStateList(GetState)
> };
>
> p_func_t jump_table[] = {
> DoStateList(GetFunc)
> };
>
>
I admit that your version is cleaner than other versions of X-macros
I've come across. I can almost even understand it.
But nearly every version I've seen /has/ been ugly, including one which
may have been in a version of Lua. (One problem still is recognising
uses of X-macros, as there is no prefix like 'xmacro' to look for. So
the current version may well have them; I can't tell.)
> Note that the states can have comments. You do need a backslash at the
> end of each line, and that means comments must be /* */ style, not //
> style.
I tried various combinations but not /*...*/ before the \.
> And since we have the x-macro in place, we can use it for more things.
> Why manually declare "extern void func0(void);", etc., when you can do
> it in two lines for all the functions?
>
> #define DeclareFunc(state, func) extern void func(void);
> DoStateList(DeclareFunc)
You can also ask why need the prototype. (My first big C app, I used a
script to process my code, which also generated two sets of function
prototypes: one for locals, one for exported. This applied to all define
functions not just the ones relating to enums.)
> Maybe you want a switch rather than a jump table - that could give more
> inlining opportunities, and is a common choice for the structure of
> things like simple VM's and bytecode interpreters:
>
> #define SwitchEntry(state, func) case state : func(); break;
> void jump(enum States s) {
> switch (s) {
> DoStateList(SwitchEntry);
> }
> }
>
That's an interesting use. But rather limited as it is, if it only
contains a function call; a table of functions is better. Here you'd
want to capture the generated output, and use that as a framework to
populate with manual code later on.
>>
>> 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
>>
>
> That is an very niche and very limited use-case. Did you seriously add
> a special feature to your language based on one example in one stack
> overflow question?
It's not limited at all. I use it very, very extensively. Virtually all
of my enums are written in this form, as most will at least have
associated names, if not other related data.
I rarely use bare enums. By contrast, most C source code uses bare enum
lists; there is very little use of X-macros.
I wonder if that would be different if they were a built-in,
easier-to-use feature?
> X macros are just an imaginative way to use a
> standard feature of C (and C++), giving vastly more flexibility than
> your single-use language feature. I have difficulty seeing how it was
> worth the effort putting that feature in your tools.
That 'feature' used to done with an external script, with input coming
from text files. Putting it into the language added only one 130-line
function, and was superior and much tidier.
> Let's try a more advanced example.
>
> #define REMOVE_COMMAS_(_1, _2, _3, _4, _5, _6, _7, _8, ...) \
> _1 _2 _3 _4 _5 _6 _7 _8
> #define REMOVE_COMMAS(...) REMOVE_COMMAS_(__VA_ARGS__, ,,,,,,,,)
<snip>
I'm sorry, but this where people get crazy with macros.
It's not just x-macros anymore, but just macros.
(Here, you will appreciate having one simple dedicated feature that you
KNOW does one thing: declare parallel enums/arrays, or arrays/arrays, in
table form.)
If I have time, I will figure out what your code is meant to do later
(it has some functions that need to be added before I can run it to see
what it does).
Then I will post a more readable version.
... OK, I had a look. I think it is good example of using macros
ingeniously, but a poor example of code as it looks terrible. I think
far from drawing things together, it looks all over the place.
I tweaked your version into a runnable program, which took 66 lines of
code. Then I took the expanded, non-macro version and tidied it up; it
was 45 lines and far more readable.
I doubt there would be that much savings in vertical space if scaled up
to a lot more commands.
It's hard to offer alternatives, since the task is unclear (using two
levels of handler code).
But, in my stuff this sort of thing typically makes use of function
reflection. So given a command "show", I can scan function names for one
called "cmd_show", but this tends to be done in a setup step that
populates a table.
The associated help text is harder; two features that might have helped
(function metadata strings and docstrings) I used to have, but have
since dropped.
However there are lots of alternatives that still be clearer than your
example (one more is given below).
> Now, some of that is messy - no doubts there. Some things could have
> been a lot easier if C macros were more powerful,
This is the danger - piling on even more features to a language already
ten times harder to code in that C.
If you're going to be adding features, how about fixing the main language?
> with features such as
> recursion or neater handling of variadic packs. Macro names scoped
> within functions would also make it better. So there's plenty of room
> for a new language to make things better than C.
> But what do we get out of this? We have all our commands defined in one
> list, with the textual name of the command, the parameters, and a help
> text. You can't get things out of sync - if you add a command, or
> change parameters, the help function, the declarations, and the
> dispatcher all adapt automatically.
If you adopted enums to represent commands, things can stay in sync too
(using my dynamic language so no types):
enumdata cmdnames, cmdhelp, cmdhandlers =
(showcmd, "show", "show help", cmd_show),
...
Look up a command in 'cmdnames[]'; if found this can be used to index
'cmdhelp[]' and 'cmdhandlers[]'. Each handler function is conventional.
> You might not think this is a good way to structure your source code.
> There are many possibilities, including more manual work, or more
> run-time work. You could use an external code generator. You could use
> a language with much better reflection capabilities (like Python). But
> this is something you can do, today, in plain C, and it shows that
> x-macros can do vastly more than declare an enumeration and a table of
> pointers.
It simply highlights my point that /because/ C can offer such untidy,
half-way solutions, it is less likely that anyone is going to touch the
main language.
>
> Now, if your language had powerful reflection and metaprogramming
> features, along with compile-time execution, so that this kind of thing
> could be done within the language without text-based macros, then I
> would happily agree that it has better features. Perhaps the way to do
> that would be to integrate your interpreted language in your compiler.
I can tell you that my 'mcc' compiler had some trouble with those macros
(but it seemed OK if I preprocessed it first then compiled that). I
don't relish going to back to my CPP 7 years on. So any solution that
doesn't stress it is preferable!
> There is a marvellous tool that might help you here - it's called "the
> internet".
That's great; I can finally learn Chinese too!
Meanwhile in these 49 numbers you will find next week's winning lottery
numbers: 1 2 3 ... 49.
> So the problem is your compiler, not other peoples' code? You think
With such a project you are forced to delve more deeply into other
people's source codes and headers than most. It can be revealing.
>> That doesn't work in inline assembly.
>>
>
> So that's a limitation of your tools.
Invoking a function from assembly involves a sequence of instructions.
In order to inline the call, means knowing how many of those
instructions are involved so that they can be replaced. Maybe the ones
directly to do with the call are intermingled with others.
It is just not practical.
> It has plenty to say about the C preprocessor - it fully defines it.
Many would disagree. Like those who have tried to implement them:
'The C99 standard is about 500 pages, but only 19 of them are dedicated
to describing how the C preprocessor should work. Most of the specs are
high level qualitative descriptions that are intended to leave lots of
freedom to the compiler implementor. It is likely that this vagueness in
this specification was intentional so that it would not cause existing
mainstream compilers (and code) to become non-conforming. Design freedom
is good for allowing people to create novel optimizations too, but to
much freedom can lead to competing interpretations.
Bjarne Stroustrup even points out that the standard isn't clear about
what should happen in function macro recursion[1]. With reference to a
specific example he says "The question is whether the use of NIL in the
last line of this sequence qualifies for non-replacement under the cited
text. If it does, the result will be NIL(42). If it does not, the
result will be simply 42.". In 2004, a decision was made to leave the
standard in its ambiguous state: "The committee's decision was that no
realistic programs "in the wild" would venture into this area, and
trying to reduce the uncertainties is not worth the risk of changing
conformance status of implementations or programs."'
https://blog.robertelder.org/7-weird-old-things-about-the-c-preprocessor/
> So MSVC has a bug. Report it if you like.
Or maybe all the others do!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-01-04 15:13 +0100 |
| Message-ID | <un6ef6$3m5sf$1@dont-email.me> |
| In reply to | #379820 |
On 03/01/2024 22:32, Bart wrote:
> On 03/01/2024 16:41, David Brown wrote:
>> On 02/01/2024 21:24, Bart wrote:
>
>> I personally like to use a slightly different syntax, but that's just
>> detail and style choice.
>>
>>
>> #define DoStateList(DO) \
>> DO(state0, func0) /* Comment */ \
>> DO(state1, func1) \
>> DO(state2, func2) \
>> DO(state3, func3) \
>>
>> #define GetState(state, func) state,
>> #define GetFunc(state, func) func,
>> #define Counter(state, func) +1
>>
>> enum { num_of_states = DoStateList(Counter) };
>>
>> enum States {
>> DoStateList(GetState)
>> };
>>
>> p_func_t jump_table[] = {
>> DoStateList(GetFunc)
>> };
>>
>>
>
> I admit that your version is cleaner than other versions of X-macros
> I've come across. I can almost even understand it.
I also think it is better this way. But I don't believe you can
/almost/ understand it - I believe you can understand it perfectly well.
(You might not like it, or see it as useful, but that's a matter of
preference and opinion.)
>
> But nearly every version I've seen /has/ been ugly, including one which
> may have been in a version of Lua. (One problem still is recognising
> uses of X-macros, as there is no prefix like 'xmacro' to look for. So
> the current version may well have them; I can't tell.)
"x-macro" is not a well-defined term. It is simply the general
technique of making a list of some sort in a macro, and using it several
times later.
>
>> Note that the states can have comments. You do need a backslash at
>> the end of each line, and that means comments must be /* */ style, not
>> // style.
>
> I tried various combinations but not /*...*/ before the \.
>
You can use /* */ comments in all sorts of places - they get treated as
white space.
>> And since we have the x-macro in place, we can use it for more things.
>> Why manually declare "extern void func0(void);", etc., when you can do
>> it in two lines for all the functions?
>>
>> #define DeclareFunc(state, func) extern void func(void);
>> DoStateList(DeclareFunc)
>
> You can also ask why need the prototype.
You don't mean "prototype" here, you mean "declaration". A function
prototype in C gives the number and types of the parameters, the name of
the function, and the return type, and can be given as a stand-alone
declaration or along with the function definition. You are asking why
we need stand-alone declarations here.
The easy answer is we need them because C requires declarations before
you can call a function or take its address. The next question is why
does C need that for functions that are defined later in the same source
file, and the answer then is that it avoids needing an extra pass in the
compiler. I would not expect newer languages to take such
considerations and need declarations (other than for imported functions,
and presumably a more modern language would use some kind of module
mechanism there).
> (My first big C app, I used a
> script to process my code, which also generated two sets of function
> prototypes: one for locals, one for exported. This applied to all define
> functions not just the ones relating to enums.)
>
>> Maybe you want a switch rather than a jump table - that could give
>> more inlining opportunities, and is a common choice for the structure
>> of things like simple VM's and bytecode interpreters:
>>
>> #define SwitchEntry(state, func) case state : func(); break;
>> void jump(enum States s) {
>> switch (s) {
>> DoStateList(SwitchEntry);
>> }
>> }
>>
>
> That's an interesting use. But rather limited as it is, if it only
> contains a function call; a table of functions is better. Here you'd
> want to capture the generated output, and use that as a framework to
> populate with manual code later on.
>
No, the "manual code" goes in the handler functions.
And no, a jump table is /not/ better - the switch is better in most ways:
1. The compiler can always implement the switch with a jump table, if
that is the most efficient method. It can choose many other ways to do
it too.
2. When the compiler can see the source of the functions (they are
defined in the same file, or you are using LTO or other whole-program
optimisation, as you do if you need top efficiency), the code can be
generated inline in the switch. That can mean reducing function call
overheads, sharing code, merging in constants, etc.
3. If the "jump" function is called in a way that the compiler can see
the parameter used, it can inline the called handler function in the
code that calls "jump", again leading to many possible optimisations.
4. Call tree analysis does not work (or works very poorly) over function
pointers. If you can avoid function pointers, programmers, compilers,
documentation tools, and static analysis tools have a vastly better
picture of the possible code flow. This lets you get high-level
overviews, trace code flow backwards, analyse stack usage, etc. It
makes debugging and code analysis much easier.
>
>>>
>>> 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
>>>
>>
>> That is an very niche and very limited use-case. Did you seriously
>> add a special feature to your language based on one example in one
>> stack overflow question?
>
> It's not limited at all. I use it very, very extensively. Virtually all
> of my enums are written in this form, as most will at least have
> associated names, if not other related data.
>
> I rarely use bare enums. By contrast, most C source code uses bare enum
> lists; there is very little use of X-macros.
>
I use enumerated types a lot, but it's rare that it would make sense in
my code to associate them with anything (names, data, actions) at that
point in the code.
> I wonder if that would be different if they were a built-in,
> easier-to-use feature?
It is possible - certainly familiarity will influence how much a
technique is used. But lots of C programmers are unaware of a good deal
of language features and standard library tools, so it is no guarantee.
Remember, the choice of features for /your/ language and library are
determined almost exclusively by what /you/ want, for the kinds of
programs /you/ write. That is the advantage of personal languages, but
it also means that comparisons of features popularity with mainstream
languages are almost completely pointless. They are of even less
validity than looking at the features a single C programmer (such as
myself) uses, or what is used in a particular C program, when trying to
judge the popularity of C features.
>
>> X macros are just an imaginative way to use a standard feature of C
>> (and C++), giving vastly more flexibility than your single-use
>> language feature. I have difficulty seeing how it was worth the
>> effort putting that feature in your tools.
>
> That 'feature' used to done with an external script, with input coming
> from text files. Putting it into the language added only one 130-line
> function, and was superior and much tidier.
>
It's neater if you don't need an external tool, yes.
>
>> Let's try a more advanced example.
>
>>
>> #define REMOVE_COMMAS_(_1, _2, _3, _4, _5, _6, _7, _8, ...) \
>> _1 _2 _3 _4 _5 _6 _7 _8
>> #define REMOVE_COMMAS(...) REMOVE_COMMAS_(__VA_ARGS__, ,,,,,,,,)
>
>
> <snip>
>
> I'm sorry, but this where people get crazy with macros.
>
> It's not just x-macros anymore, but just macros.
I fully appreciate that it requires more effort to understand such
macros, and their use is not to everyone's taste. People who use these
things generally have a collection of macros they like in a header, and
use them as needed without worrying about the details. Mostly the
macros will come from elsewhere. Actually, all that sounds just like
programming as usual - it's what programmers do all the time, in any
language. Very, very few programmers limit themselves to only ever
using code they write themselves or understand themselves.
>
> (Here, you will appreciate having one simple dedicated feature that you
> KNOW does one thing: declare parallel enums/arrays, or arrays/arrays, in
> table form.)
Sure - when that feature is sufficient. I was giving an example of
something a lot more complicated than you can do with your features. It
does not mean that's the only way to do it, or necessarily the best way
to do it (for whatever value of "best" you pick) - it's just a possibility.
>
> If I have time, I will figure out what your code is meant to do later
> (it has some functions that need to be added before I can run it to see
> what it does).
>
> Then I will post a more readable version.
OK.
>
> ... OK, I had a look. I think it is good example of using macros
> ingeniously, but a poor example of code as it looks terrible. I think
> far from drawing things together, it looks all over the place.
>
It puts things in /different/ places than you might normally do. That
splits some things up, and combines other things.
> I tweaked your version into a runnable program, which took 66 lines of
> code. Then I took the expanded, non-macro version and tidied it up; it
> was 45 lines and far more readable.
Now imagine there were 24 commands, not 4. The implementation of the
command handlers must, of course, be written regardless of the
implementation - but apart from that the macro version only needs 20 new
lines to declare the new commands. Everything else adapt automatically.
But a "traditional" solution would need changes to the help function
and the dispatch function as well.
Now consider putting the "DoCommandList" in a header file "commands.h",
along with the "DeclareFunc" bits. The file "commands.c" will include
the "commands.h" file and hold the implementation of all the command
handlers, except cmd_help and perhaps a few other generic commands. The
file "cli_base.c" will hold all the other macros and calls, and can have
things like the "get_int_param" parsers.
So now you have a complete separation of tasks. Adding new commands
doesn't involve changes to the base part at all, which can be common for
different projects. The project-specific part - the list of commands
and their handler implementation - is all neatly in one file, which is
free from all the implementation details and complicated macros.
You don't use a system like this for four things in a list - you use it
when you have lots.
>
> I doubt there would be that much savings in vertical space if scaled up
> to a lot more commands.
>
> It's hard to offer alternatives, since the task is unclear (using two
> levels of handler code).
>
> But, in my stuff this sort of thing typically makes use of function
> reflection. So given a command "show", I can scan function names for one
> called "cmd_show", but this tends to be done in a setup step that
> populates a table.
>
> The associated help text is harder; two features that might have helped
> (function metadata strings and docstrings) I used to have, but have
> since dropped.
>
> However there are lots of alternatives that still be clearer than your
> example (one more is given below).
>
>> Now, some of that is messy - no doubts there. Some things could have
>> been a lot easier if C macros were more powerful,
>
> This is the danger - piling on even more features to a language already
> ten times harder to code in that C.
Macros are /not/ that hard to use - and the preprocessor is not a
"language" but an inherent part of C.
But greater power and more features of macros would make it /easier/ to
use. Imagine, for example, how the "REMOVE_COMMAS" macros could work if
the C preprocessor supported recursion and overloading on the number of
parameters - relatively easy extensions. (I'll also use the gcc feature
of giving a name to the "..." bit, instead of the ugly __VA_ARGS__.)
Currently, we have :
#define REMOVE_COMMAS_(_1, _2, _3, _4, _5, _6, _7, _8, ...) \
_1 _2 _3 _4 _5 _6 _7 _8
#define REMOVE_COMMAS(...) REMOVE_COMMAS_(__VA_ARGS__, ,,,,,,,,)
If I want that to work with more than 8 parameters, I need to extend it
with more placeholders and more commas (which would be even messier in a
Usenet post). But with my suggested features, you'd have:
#define REMOVE_COMMAS()
#define REMOVE_COMMAS(x, args...) x REMOVE_COMMAS(args)
/Much/ better.
You can google for variadic "FOR_EACH" macro implementations, that let
you write "FOR_EACH(DO, ...)" and apply the macro "DO" to each parameter
in the following list. Such macros can be handy in some coding
situations, but the implementations are very messy - you'd want to hide
them away in an include file and never look at them again, and they also
always have limits on the number of parameters. With my suggested added
features, "FOR_EACH" would be defined as:
#define FOR_EACH(DO)
#define FOR_EACH(DO, x, args...) DO(x) FOR_EACH(DO, args)
Again, simple, clean recursion. And REMOVE_COMMAS could be :
#define ID(x) x
#define REMOVE_COMMAS(args) FOR_EACH(ID, args)
Of course more power gives more opportunities to make a mess and write
bad code - but it also gives more opportunities to write /good/ code.
>
> If you're going to be adding features, how about fixing the main language?
That's a topic for another thread :-)
>
>> with features such as recursion or neater handling of variadic packs.
>> Macro names scoped within functions would also make it better. So
>> there's plenty of room for a new language to make things better than C.
>
>> But what do we get out of this? We have all our commands defined in
>> one list, with the textual name of the command, the parameters, and a
>> help text. You can't get things out of sync - if you add a command,
>> or change parameters, the help function, the declarations, and the
>> dispatcher all adapt automatically.
>
> If you adopted enums to represent commands, things can stay in sync too
> (using my dynamic language so no types):
>
> enumdata cmdnames, cmdhelp, cmdhandlers =
> (showcmd, "show", "show help", cmd_show),
> ...
>
Different commands need different numbers and types of parameters.
> Look up a command in 'cmdnames[]'; if found this can be used to index
> 'cmdhelp[]' and 'cmdhandlers[]'. Each handler function is conventional.
>
>
>> You might not think this is a good way to structure your source code.
>> There are many possibilities, including more manual work, or more
>> run-time work. You could use an external code generator. You could
>> use a language with much better reflection capabilities (like
>> Python). But this is something you can do, today, in plain C, and it
>> shows that x-macros can do vastly more than declare an enumeration and
>> a table of pointers.
>
> It simply highlights my point that /because/ C can offer such untidy,
> half-way solutions, it is less likely that anyone is going to touch the
> main language.
>
You have a different attitude to language design than mainstream
language developers do, because you have /personal/ languages and tools.
If you want to add something to your language, you just add a couple
of hundred lines of code to your compiler - it's as easy to add it to
the language and compiler as to add it to the application code written
in the language. But for real languages, it's a /completely/ different
matter. Adding an "enumdata" feature to C would be, at a wild estimate,
many thousands of manhours work. It would need to be proposed, in a
paper that considered use-cases, alternatives, names, details,
specifications, changes to the wording of the C standards. It would
need to be discussed and considered by many people. Prototype
implementations would be needed, along with people testing it. People
would have to consider conflicts with existing code, such as a a
conflict between the new keyword and existing identifiers. Corner cases
and interaction with other features would need to be considered and
handled, such as interoperability with other enumeration types. It has
to go into the standards drafts, and be voted upon. Compiler
implementers need to write it, test it, document it, create test cases,
analyse the efficiency of the generated code, suggest changes. People
have to add it to their C books, tutorials, courses, blogs.
Compare that to just writing a few lines of ugly macros and explaining
them in a blog post. The hurdles for considering changing the core C
language are significant.
The more popular and established a language is, the harder it is to
change it - so there is a huge contrast between the world's most used
and best established language, and one of the world's least used and
least established languages. Obviously the benefits from improving the
language are also in contrast - improvements to your language help you
and no one else, while improvements to C could help hundreds of
thousands of developers, and countless millions of end users. But the
path getting there is very different.
>
>>
>> Now, if your language had powerful reflection and metaprogramming
>> features, along with compile-time execution, so that this kind of
>> thing could be done within the language without text-based macros,
>> then I would happily agree that it has better features. Perhaps the
>> way to do that would be to integrate your interpreted language in your
>> compiler.
>
> I can tell you that my 'mcc' compiler had some trouble with those macros
> (but it seemed OK if I preprocessed it first then compiled that). I
> don't relish going to back to my CPP 7 years on. So any solution that
> doesn't stress it is preferable!
>
>
>> There is a marvellous tool that might help you here - it's called "the
>> internet".
>
> That's great; I can finally learn Chinese too!
>
> Meanwhile in these 49 numbers you will find next week's winning lottery
> numbers: 1 2 3 ... 49.
>
>> So the problem is your compiler, not other peoples' code? You think
>
> With such a project you are forced to delve more deeply into other
> people's source codes and headers than most. It can be revealing.
>
It can also be irrelevant. You get hung up on details that don't matter.
>
>>> That doesn't work in inline assembly.
>>>
>>
>> So that's a limitation of your tools.
>
> Invoking a function from assembly involves a sequence of instructions.
>
> In order to inline the call, means knowing how many of those
> instructions are involved so that they can be replaced. Maybe the ones
> directly to do with the call are intermingled with others.
>
> It is just not practical.
Some other compilers do it fine (though some other compilers share your
limitations). I don't doubt that it would take effort, and I can quite
believe that it is simply not worth the effort for you - your time and
energy is not unlimited. But it is still a limitation of your compiler
that is not inherent in the use of assembly mixed with a language like C.
>
>
>> It has plenty to say about the C preprocessor - it fully defines it.
>
> Many would disagree. Like those who have tried to implement them:
>
> 'The C99 standard is about 500 pages, but only 19 of them are dedicated
> to describing how the C preprocessor should work. Most of the specs are
> high level qualitative descriptions that are intended to leave lots of
> freedom to the compiler implementor. It is likely that this vagueness in
> this specification was intentional so that it would not cause existing
> mainstream compilers (and code) to become non-conforming. Design freedom
> is good for allowing people to create novel optimizations too, but to
> much freedom can lead to competing interpretations.
>
> Bjarne Stroustrup even points out that the standard isn't clear about
> what should happen in function macro recursion[1]. With reference to a
> specific example he says "The question is whether the use of NIL in the
> last line of this sequence qualifies for non-replacement under the cited
> text. If it does, the result will be NIL(42). If it does not, the
> result will be simply 42.". In 2004, a decision was made to leave the
> standard in its ambiguous state: "The committee's decision was that no
> realistic programs "in the wild" would venture into this area, and
> trying to reduce the uncertainties is not worth the risk of changing
> conformance status of implementations or programs."'
>
> https://blog.robertelder.org/7-weird-old-things-about-the-c-preprocessor/
>
OK, so it is /almost/ fully defined. Few things in life are perfect,
and that includes the C standards. It is, however, good enough to cover
pretty much every preprocessor usage you'll find in real life, outside
of the OCCC.
>> So MSVC has a bug. Report it if you like.
>
> Or maybe all the others do!
>
Maybe :-)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-03 13:42 -0800 |
| Message-ID | <87il4at7pf.fsf@nosuchdomain.example.com> |
| In reply to | #379814 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/01/2024 21:24, Bart wrote:
[...]
>> 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
>> };
>> -------
>
> (Why did you change the type from "p_func_t" to "void*" ? Was it just
> to annoy myself and other C programmers with a pointless and
> constraint-violating cast of a function pointer to "void*" ? Just add
> a suitable typedef - "typedef void(*p_func_t)(void);" )
What constraint does it violate? And what cast are you referring to?
[...]
>> 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!)
>>
>
> So MSVC has a bug. Report it if you like.
Not necessarily. With clang, I get:
$ clang c.c -o c && ./c
c.c:5:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
#if BAR
^
c.c:4:13: note: expanded from macro 'BAR'
#define BAR defined(FOO)
^
1 warning generated.
BAR
I haven't taken the time to convince myself that clang is correct, but
see N1570 6.10.1p4.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 29 of 34 — ← Prev page 1 … 27 28 [29] 30 31 … 34 Next page →
Back to top | Article view | comp.lang.c
csiph-web