Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167206 > unrolled thread
| Started by | antispam@math.uni.wroc.pl |
|---|---|
| First post | 2022-08-25 02:33 +0000 |
| Last post | 2022-08-25 20:30 +0000 |
| Articles | 20 on this page of 236 — 17 participants |
Back to article view | Back to comp.lang.c
Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 02:33 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 03:00 +0000
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-26 00:22 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-26 16:48 +0000
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 03:01 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 14:29 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:10 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 16:23 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-25 20:53 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 06:56 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-26 17:29 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 13:44 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 16:01 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 10:27 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-28 03:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 15:05 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:00 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 15:16 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 09:38 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-30 04:03 -0700
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@gmail.com> - 2022-08-31 01:20 +0300
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 09:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:19 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:11 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 17:20 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:31 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-28 21:29 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 02:58 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 19:51 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 10:54 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-12 05:13 -0700
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 13:55 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 15:06 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 15:22 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 17:04 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:39 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:40 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:52 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 17:24 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:55 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:51 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 14:57 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 00:46 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 16:13 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 08:47 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:13 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:30 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:36 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 00:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 10:44 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 04:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 05:48 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:31 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:15 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 16:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:43 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 18:37 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 19:30 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 18:47 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:37 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 19:47 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 09:45 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 11:55 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 05:23 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 14:20 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:20 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 00:25 +0000
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:46 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:11 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 12:54 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:52 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 21:08 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:46 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 01:25 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 11:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 12:04 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 16:06 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 23:24 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 11:39 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 18:57 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-02 17:37 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 23:51 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 01:23 +0000
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 20:42 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 14:34 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 17:39 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 12:00 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 14:45 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 17:40 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 17:30 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-04 15:02 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-04 22:45 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 01:02 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 08:22 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 12:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 15:15 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 22:54 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 22:49 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:05 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:41 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 09:39 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 10:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 15:29 +0200
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-06 17:05 +0300
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 15:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 17:19 +0200
Re: Are there any conformant C compilers? tTh <tth@none.invalid> - 2022-09-06 18:19 +0200
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-09-08 06:18 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 18:10 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-07 20:31 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-07 19:41 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 22:05 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-08 10:07 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:42 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 23:11 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:03 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:02 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-05 12:27 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:40 +0000
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-05 14:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 20:24 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 22:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 00:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 12:35 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 14:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 15:20 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 15:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 18:00 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-04 19:26 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 16:24 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 18:23 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 06:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:06 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 12:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:19 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 16:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:45 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 10:04 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 04:59 -0700
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-08-29 07:32 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 16:47 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 17:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 13:15 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 14:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 15:54 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:17 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 18:34 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 11:25 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:14 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:28 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 15:02 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 17:06 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 15:29 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:48 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 19:58 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:31 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 13:01 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 15:26 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 15:42 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:00 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 04:35 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-01 15:10 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 00:09 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 09:30 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 13:24 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 05:56 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 15:14 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 16:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 17:52 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 10:01 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 12:18 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:45 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:08 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 21:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 23:29 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 16:25 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:23 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 13:07 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 15:06 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:22 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 12:01 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:40 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-12 12:32 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-12 09:33 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:34 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 16:41 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:41 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 11:06 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 01:03 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 06:52 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 00:14 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 17:29 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-19 02:33 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:07 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:03 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:47 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 16:01 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 19:22 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 10:50 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 00:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 21:35 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 07:58 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:49 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:02 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 18:36 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:25 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 05:31 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:08 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:40 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:50 -0700
Re: Are there any conformant C compilers? Opus <ifonly@youknew.org> - 2022-08-27 20:04 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 17:03 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:50 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 12:04 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 12:25 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:23 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:58 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 07:51 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 11:50 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 19:45 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 22:03 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-27 08:14 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-27 11:23 -0700
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-25 12:41 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 20:30 +0000
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-05 23:03 +0000 |
| Message-ID | <MevRK.14735$1Ly7.2340@fx34.iad> |
| In reply to | #167500 |
Bart <bc@freeuk.com> writes: >On 05/09/2022 22:42, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 05/09/2022 07:22, David Brown wrote: >>>> On 05/09/2022 02:02, Bart wrote: >>>>> >>>>> I tried such a simple register allocator a couple of years ago, which >>>>> just kept some locals in registers when there were spare registers. >>>>> >>>>> When applied to typical benchmarks, it worked pretty well. >>>>> >>>>> On real applications, it made a lot less difference, especially when I >>>>> switched machines (from older Intel to newer AMD), then often it made >>>>> no measurable difference. >>>>> >>>>> So I'm looking at not bothering with optimisation at all. This is >>>>> because the difference between gcc-O3 (ver. 10.x), and my unoptimised >>>>> code is not that much for my programs anyway. >>>>> >>>>> Typically mine will be half the speed of gcc -O3 (gcc code takes 50% >>>>> less runtime). Here gcc takes 33% less runtime than mine: >>>>> >>>> >>>> At the higher end, people pay several times as much for chips that are >>>> less than 33% faster. Of course speed does not always matter, but >>>> sometimes it does. >>> >>> Actually 33% less runtime means 50% faster. >>> >>> But remember that scripting languages are also tremendously popular, >>> which can be 1-2 /magnitudes/ slower than optimised C code. >>> >>> So even a C compiler such as Tiny C can be significantly faster than >>> such languages for implementing the same programs. >>> >>> (In fact, Tiny C compiling itself still results in a compiler that runs >>> rings around most others. I thought it was due to its using gcc -O3, but >>> that's only part of it. Here: >>> >>> https://github.com/sal55/langs/blob/master/Compilertest3.md >>> >>> tcc variations occupy all four entries at the end of the first table, >>> the fast end.) >> >> As as been noted before, compilation speed is an irrelevent benchmark. >> >> It's not like the compiler is limited to the speed of the card reader >> anymore. >> >> The speed of the "compiled" code is much more relevent. > >Why? How important is it actually? What proportion of builds are for >finished production executables that will be run 1000s of times to make >the extra compile-time worthwhile? > >Here are some actual measurements I just posted in a reply to David Brown: > > c:\oldqx>tm gcc -O3 qq.c > TM: 15.27 > > c:\oldqx>tm tcc qq.c > TM: 0.08 > >Please tell why I need to hang about 200 times longer for a program I >might run once. Sure, gcc -O0 will be faster (it only takes 36 times as >long), but the code is just as slow, so what's the point? (As I said >there, this C code has been verified.) Because it takes you 15 seconds to blink. If you were talking about reducing a 1 hour compile to 15 seconds, that would be interesting. 15 to .8 seconds is in the noise. And tcc would not be usable for 90% of the C code currently in production anyway given the lack of any sophisticated optimization techniques or common extensions, or support for recent standards. You are comparing apples to oranges, which is a meaningless comparison.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-06 01:02 +0100 |
| Message-ID | <tf62m0$1027$1@gioia.aioe.org> |
| In reply to | #167501 |
On 06/09/2022 00:03, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> Please tell why I need to hang about 200 times longer for a program I >> might run once. Sure, gcc -O0 will be faster (it only takes 36 times as >> long), but the code is just as slow, so what's the point? (As I said >> there, this C code has been verified.) > > Because it takes you 15 seconds to blink. > > > If you were talking about reducing a 1 hour compile to 15 seconds, that > would be interesting. 15 to .8 seconds is in the noise. And tcc would > not be usable for 90% of the C code currently in production anyway > given the lack of any sophisticated optimization techniques or common > extensions, or support for recent standards. (1) It's 0.08 seconds, not 0.8 seconds (2) 0.08s might well be a blink, but 15 seconds feels like forever to me to have to twiddle my thumbs for a trivial task to finish. (Why do you think no one likes stopping at red lights?) (3) My programs are small; for others the benefits are greated. The same speed-up applied to your 1-hour build using gcc-O3, would take 20 seconds with tcc ... (4) ... except that, since it generates code at some 10MB per second, it would produce a huge 200MB executable. 99% of the binaries on my machine are far smaller. > You are comparing apples to oranges, which is a meaningless comparison. I want to get from A to B with as little fuss and effort as possible. I'm not interested in sight-seeing or scenic detours or opulent luxury. Because I will be doing the journey 100s of times a day, and will not be spending enough time at B to make a considerably longer journey time worthwhile. When that is the case, then somebody else can take over and use whatever means they like. > And tcc would > not be usable for 90% of the C code currently in production anyway > given the lack of any sophisticated optimization techniques or common > extensions, or support for recent standards. Perhaps a fraction of the effort spent on products like gcc can be applied to tcc to bring it up to scratch. I'd quite like to see it as a secretly bundled compiler within gcc, invoked via -O-1.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-09-05 12:27 +0000 |
| Message-ID | <tf4q0b$925$1@gioia.aioe.org> |
| In reply to | #167484 |
Bart <bc@freeuk.com> wrote:
> On 04/09/2022 23:45, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
> >> On 03/09/2022 16:40, David Brown wrote:
> >>> On 03/09/2022 15:45, Bart wrote:
> >>
> >>>> ?From a comment of David Brown, and your [antispam's] own remark,
> >>>> 'register' may no longer literally mean to use a register, but is used
> >>>> as an attribute to inhibit using &.
> >>>
> >>> Of course, "used" is a strong word here - the "register" keyword is
> >>> almost unknown in modern C programming.? It has already been deprecated
> >>> in C++, where it had the same meaning, and no one really noticed.
> >>>
> >>> If there are some compilers that have the kind of problems you worry
> >>> about with register variables taking up processor registers, it really
> >>> doesn't matter.? Such compilers might be good for teaching, research,
> >>> fun, or when you want a very small or very fast tool - but no one cares
> >>> about them when they are interested in generating fast object code.
> >>
> >> You seem very deprecating of such things (of course, you usually get
> >> someone else to write your compilers for you!).
> >>
> >> I'm thinking of introducing such a feature myself although it will more
> >> be of a hint that a variable will be heavily used. (It'll be separate
> >> from the declaration; it can be used for globals; and is an experiment
> >> to see how worthwhile it might be).
> >
> > There is _very_ simple register allocation method that is likely to
> > do better than looking at 'register' to do register allocation.
> > I am working now on compiler backend that is uing moral equivalent
> > on 'register' declaration: first N variables are allocated in
> > registers. And I see that this leads to much worse quality
> > than otherwise possible. Namely, bunch of registers are
> > reserverd for temporaries and unavailable to normal variables.
> > Since number of temporary registers is limited and there is
> > no real allocater intermediate results are frequently forced
> > to memory. They are reloaded from memory even if a copy is
> > available in a register. So computation suffers due to
> > lack of temporary registers (and smart management of register).
> > OTOH there are cases when work could be done just on variables,
> > so temporary registers are almost unused, but some variables
> > end in memory due to fact that registers are reserved for
> > temporaries.
> >
> > Let me put it differenty: main issue is allocation for temporaries.
> > 'register' variables may help a bit if author allocates
> > crucial temporaries to variables and re-uses them when
> > free. I would not count on normal user doing this in
> > useful way. Of course, you know about compilation so
> > you may be able to do better job of "register allocation by
> > hand". Still, getting real register allocator seem to be
> > better solution.
> >
>
> I tried such a simple register allocator a couple of years ago, which
> just kept some locals in registers when there were spare registers.
>
> When applied to typical benchmarks, it worked pretty well.
>
> On real applications, it made a lot less difference, especially when I
> switched machines (from older Intel to newer AMD), then often it made no
> measurable difference.
>
> So I'm looking at not bothering with optimisation at all. This is
> because the difference between gcc-O3 (ver. 10.x), and my unoptimised
> code is not that much for my programs anyway.
>
> Typically mine will be half the speed of gcc -O3 (gcc code takes 50%
> less runtime). Here gcc takes 33% less runtime than mine:
>
> c:\cx>tm ccgcc sql -c
> Compiling sql.c to sql.obj
> TM: 0.27
>
> c:\cx>tm cc sql -c
> Compiling sql.c to sql.obj
> TM: 0.40 (0.38 when optimised!)
>
> The application is 'cc', my C compiler. ccgcc.exe was created with gcc
> -O3 via a C rendering, cc.exe is my unoptimised code, and the task is
> compiling a 250Kloc application (a lot bigger than typical input). (Tcc
> here takes 0.46 seconds.)
In language like C accesses to global variables are mostly determined
by program and compiler can not do much about them. So you see
improvements with handling of temporaries and local variables,
but not much improvements for globals. In program is dominated
by memory access, then you do not see much improvement.
Compilers tend to be bad in this aspect, as much of compiler work
is access to various tables scattered over memory. AFAICS
your compiler probably could be improved here, you have
several "parallel" tables, putting entries that are accessed
together in single table could significantly improve speed
of memory access.
I real world there are also applications were memory access
is well optimized, and those see big improvements from
compiler optimizations.
Another thing is that say 10% speedup is good if only that
you need to do to get it is crank up compiler optimization
options.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-05 21:40 +0000 |
| Message-ID | <m1uRK.7568$I0A5.2230@fx04.iad> |
| In reply to | #167483 |
antispam@math.uni.wroc.pl writes: >Bart <bc@freeuk.com> wrote: >> On 03/09/2022 16:40, David Brown wrote: >> > On 03/09/2022 15:45, Bart wrote: >> >> >> ?From a comment of David Brown, and your [antispam's] own remark, >> >> 'register' may no longer literally mean to use a register, but is used >> >> as an attribute to inhibit using &. >> > >> > Of course, "used" is a strong word here - the "register" keyword is >> > almost unknown in modern C programming.? It has already been deprecated >> > in C++, where it had the same meaning, and no one really noticed. >> > >> > If there are some compilers that have the kind of problems you worry >> > about with register variables taking up processor registers, it really >> > doesn't matter.? Such compilers might be good for teaching, research, >> > fun, or when you want a very small or very fast tool - but no one cares >> > about them when they are interested in generating fast object code. >> >> You seem very deprecating of such things (of course, you usually get >> someone else to write your compilers for you!). >> >> I'm thinking of introducing such a feature myself although it will more >> be of a hint that a variable will be heavily used. (It'll be separate >> from the declaration; it can be used for globals; and is an experiment >> to see how worthwhile it might be). > >There is _very_ simple register allocation method that is likely to >do better than looking at 'register' to do register allocation. >I am working now on compiler backend that is uing moral equivalent >on 'register' declaration: first N variables are allocated in >registers. And I see that this leads to much worse quality >than otherwise possible. Namely, bunch of registers are >reserverd for temporaries and unavailable to normal variables. >Since number of temporary registers is limited and there is >no real allocater intermediate results are frequently forced >to memory. They are reloaded from memory even if a copy is >available in a register. So computation suffers due to >lack of temporary registers (and smart management of register). >OTOH there are cases when work could be done just on variables, >so temporary registers are almost unused, but some variables >end in memory due to fact that registers are reserved for >temporaries. > >Let me put it differenty: main issue is allocation for temporaries. 'tis truth, forsooth. Note that the Sethi-Ullman algorithm describing temporary allocation strategies is documented in the second edition of the Dragon book.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-09-05 14:55 -0700 |
| Message-ID | <tf5r99$3me7j$1@dont-email.me> |
| In reply to | #167496 |
On 9/5/2022 2:40 PM, Scott Lurndal wrote: > antispam@math.uni.wroc.pl writes: >> Bart <bc@freeuk.com> wrote: >>> On 03/09/2022 16:40, David Brown wrote: >>>> On 03/09/2022 15:45, Bart wrote: >>> >>>>> ?From a comment of David Brown, and your [antispam's] own remark, >>>>> 'register' may no longer literally mean to use a register, but is used >>>>> as an attribute to inhibit using &. >>>> >>>> Of course, "used" is a strong word here - the "register" keyword is >>>> almost unknown in modern C programming.? It has already been deprecated >>>> in C++, where it had the same meaning, and no one really noticed. >>>> >>>> If there are some compilers that have the kind of problems you worry >>>> about with register variables taking up processor registers, it really >>>> doesn't matter.? Such compilers might be good for teaching, research, >>>> fun, or when you want a very small or very fast tool - but no one cares >>>> about them when they are interested in generating fast object code. >>> >>> You seem very deprecating of such things (of course, you usually get >>> someone else to write your compilers for you!). >>> >>> I'm thinking of introducing such a feature myself although it will more >>> be of a hint that a variable will be heavily used. (It'll be separate >>> from the declaration; it can be used for globals; and is an experiment >>> to see how worthwhile it might be). >> >> There is _very_ simple register allocation method that is likely to >> do better than looking at 'register' to do register allocation. >> I am working now on compiler backend that is uing moral equivalent >> on 'register' declaration: first N variables are allocated in >> registers. And I see that this leads to much worse quality >> than otherwise possible. Namely, bunch of registers are >> reserverd for temporaries and unavailable to normal variables. >> Since number of temporary registers is limited and there is >> no real allocater intermediate results are frequently forced >> to memory. They are reloaded from memory even if a copy is >> available in a register. So computation suffers due to >> lack of temporary registers (and smart management of register). >> OTOH there are cases when work could be done just on variables, >> so temporary registers are almost unused, but some variables >> end in memory due to fact that registers are reserved for >> temporaries. >> >> Let me put it differenty: main issue is allocation for temporaries. > > 'tis truth, forsooth. > > Note that the Sethi-Ullman algorithm describing temporary allocation > strategies is documented in the second edition of the Dragon book. > For some damn reason, this is making me think of a stack based region allocator: https://pastebin.com/raw/f37a23918 https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-03 20:24 +0100 |
| Message-ID | <871qssfegl.fsf@bsb.me.uk> |
| In reply to | #167458 |
Bart <bc@freeuk.com> writes: > constexpr int = 123; # Can use & > > All with their own limitations, a few of which are highlighted. Why is that a limitation? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-03 22:30 +0100 |
| Message-ID | <tf0h1c$t79$1@gioia.aioe.org> |
| In reply to | #167465 |
On 03/09/2022 20:24, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> constexpr int = 123; # Can use & >> >> All with their own limitations, a few of which are highlighted. > > Why is that a limitation? It's undesirable if you want proper separation between values and objects in a language. And if you a want a user to be confident of that difference (and not be worried that their values can become inadvertently or deliberately corrupted). But I guess C doesn't care about that purity, and perhaps you don't either. Given a compile-time Value, whether a direct literal, a named alias for a literal, or an alias for a expression that has such a value, applying address-of should be meaningless. But with a named alias for an object (some notional location inside a running program that contains a value), then address-of should always work - it yields the address of that location. The latter might need read-only control to (try and) stop you writing into that location. This should never be needed for a value, as there is no location. In practice there can be overlap between the two concepts for more elaborate types, but you can still try and keep to the principles. My stuff manages to keep them separate a bit better than C does. Apart from &, with C's const/constexpr, there is also nothing that stops another module having their own declaration of any such variable, but without 'const', or having a totally different type. A lot of fun and games can be had that way, that can be largely avoided by having named values that have no location and no linkage.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-04 00:19 +0100 |
| Message-ID | <87k06kdp18.fsf@bsb.me.uk> |
| In reply to | #167470 |
Bart <bc@freeuk.com> writes: > On 03/09/2022 20:24, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> constexpr int = 123; # Can use & >>> >>> All with their own limitations, a few of which are highlighted. >> Why is that a limitation? > > It's undesirable if you want proper separation between values and > objects in a language. Yes, it's undesirable (if you want that). I wondered why you thought it was a /limitation/ -- i.e. that you had some use in mind that is ruled out by the possibility of using &. (Yes, I know that, rather formally, any negative like this is a limitation in that the programmer is limited by not having the corresponding positive, but I thought you were talking in practical terms.) > And if you a want a user to be confident of that difference (and not > be worried that their values can become inadvertently or deliberately > corrupted). > > But I guess C doesn't care about that purity, and perhaps you don't > either. No one with even the slightest interest in purity looks to C. C's phenomenal success is a constant embarrassment to anyone advocating for pure language design. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-04 12:35 +0100 |
| Message-ID | <tf22ie$10bk$1@gioia.aioe.org> |
| In reply to | #167471 |
On 04/09/2022 00:19, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 03/09/2022 20:24, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> constexpr int = 123; # Can use & >>>> >>>> All with their own limitations, a few of which are highlighted. >>> Why is that a limitation? >> >> It's undesirable if you want proper separation between values and >> objects in a language. > > Yes, it's undesirable (if you want that). I wondered why you thought it > was a /limitation/ -- i.e. that you had some use in mind that is ruled > out by the possibility of using &. Perhaps the wrong choice of word then; maybe 'hindrance' is better if looking for a way to express such a feature in C. Imagine transpiling from a language that implements it as you would expect, into maintainable C code. (That is, not temporary code that is only ever seen by a compiler; then you'd just write out actual literals.) Which C features would you choose? Maybe 'limited' was apt after all. >> But I guess C doesn't care about that purity, and perhaps you don't >> either. > > No one with even the slightest interest in purity looks to C. C's > phenomenal success is a constant embarrassment to anyone advocating for > pure language design. > I feel, not embarrassment, but frustration when C is touted as being THE example of a language that is small, simple, clean (compared with C++!), explicit, close-to-the-metal, you know all the rest. It's various quirks are seen as something that have to be learnt and that comes with the territory. A whole generation doesn't realise that there could possibly be any alternative, if you want a small-footprint systems language that can be implemented (if using tcc) in 180KB and that can build programs at 1Mlps (not much chance of such a compiler for Rust). I'm not saying an alternative ought to look like my product (which is a private tool anyway) but, yeah, you're right, it's embarrassing when the only such language that can be recommended is C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-04 14:17 +0100 |
| Message-ID | <8735d7e0sv.fsf@bsb.me.uk> |
| In reply to | #167472 |
Bart <bc@freeuk.com> writes:
> On 04/09/2022 00:19, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 03/09/2022 20:24, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> constexpr int = 123; # Can use &
>>>>>
>>>>> All with their own limitations, a few of which are highlighted.
>>>> Why is that a limitation?
>>>
>>> It's undesirable if you want proper separation between values and
>>> objects in a language.
>> Yes, it's undesirable (if you want that). I wondered why you thought it
>> was a /limitation/ -- i.e. that you had some use in mind that is ruled
>> out by the possibility of using &.
>
> Perhaps the wrong choice of word then; maybe 'hindrance' is better if
> looking for a way to express such a feature in C.
>
> Imagine transpiling from a language that implements it as you would
> expect, into maintainable C code. (That is, not temporary code that is
> only ever seen by a compiler; then you'd just write out actual
> literals.)
>
> Which C features would you choose? Maybe 'limited' was apt after all.
auto constexpr.
But if the maintainer of the code going to be the knuckle-dragging,
barely literate code monkey common to popular discussions of
maintainable code, I'd go with
auto constexpr ... /* Turn on ALL compiler warnings and check each
message, twice. The overtime will be cheap given
your salary. */
>>> But I guess C doesn't care about that purity, and perhaps you don't
>>> either.
>> No one with even the slightest interest in purity looks to C. C's
>> phenomenal success is a constant embarrassment to anyone advocating for
>> pure language design.
>
> I feel, not embarrassment, but frustration when C is touted as being
> THE example of a language that is small, simple, clean (compared with
> C++!), explicit, close-to-the-metal, you know all the rest.
I've never seen it touted like that. In the circles I moved in, it has
always been considered a dangerous language, particularly in the hands
of the inexperienced. It was seen as useful for portability (almost
nothing comes close) and for the fact almost everything else could link
to C libraries. When these mattered, my impression was the C was
chosen, rather reluctantly, and the coding given to the best people.
> A whole generation doesn't realise that there could possibly be any
> alternative, if you want a small-footprint systems language that can
> be implemented (if using tcc) in 180KB and that can build programs at
> 1Mlps (not much chance of such a compiler for Rust).
Curious. Which generation is that, and why do they care about the
implementation footprint? I want top-class editors, compilers, linkers
and debugging tools like valgrind and gcc's -fsanitize=undefined option
for development.
There was a generation (mine) for whom 180KB for a compiler was out of
the question (unless you wanted to fuss about with overlays). We
accepted a very restricted notion of what a compiler could do as a
result.
> I'm not saying an alternative ought to look like my product (which is
> a private tool anyway) but, yeah, you're right, it's embarrassing when
> the only such language that can be recommended is C.
That's not what I said. The embarrassment I was referring to was that
of people who think that purity is (or should be) a winning feature.
Languages succeed for a very complex constellation of reasons, and the
elegance of the design does not rank very high. The is partly because
humans don't mind some linguistic complexity (compare English and
Esperanto) but it's mostly down to socio-economic factors.
There is also a curious logical reason for C's popularity. There will
always be a most portable and most linkable language, and C was one of
the first candidates. Only Fortran came close, and if you think C is
quirky, try old Fortran. Thus C had a head start and so new platforms
had to have to have C to get all the portable code and libraries! So
the front runner gets further ahead.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-04 15:20 +0100 |
| Message-ID | <tf2c70$tdo$1@gioia.aioe.org> |
| In reply to | #167474 |
On 04/09/2022 14:17, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 04/09/2022 00:19, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> On 03/09/2022 20:24, Ben Bacarisse wrote: >>>>> Bart <bc@freeuk.com> writes: >>>>> >>>>>> constexpr int = 123; # Can use & >>>>>> >>>>>> All with their own limitations, a few of which are highlighted. >>>>> Why is that a limitation? >>>> >>>> It's undesirable if you want proper separation between values and >>>> objects in a language. >>> Yes, it's undesirable (if you want that). I wondered why you thought it >>> was a /limitation/ -- i.e. that you had some use in mind that is ruled >>> out by the possibility of using &. >> >> Perhaps the wrong choice of word then; maybe 'hindrance' is better if >> looking for a way to express such a feature in C. >> >> Imagine transpiling from a language that implements it as you would >> expect, into maintainable C code. (That is, not temporary code that is >> only ever seen by a compiler; then you'd just write out actual >> literals.) >> >> Which C features would you choose? Maybe 'limited' was apt after all. > > auto constexpr. So you'd represent a low level feature with simple, precise semantics into a heavyweight, higher level one with a behaviour dependent on crossing your fingers and hoping it all comes out alright. I've not actually done this (mainly going the other way in translating heaps of #defines into something better), but I might use a two level solution: - enum for int values that fit into 32 bits - #defines for anything else, but I might need to decorate the names to avoid name clashes I'm doubtful of this however - the source language would most likely use 64-bit ints, and having 32-bit enum names would require untidy casts everywhere (remember it has to be readable). But maybe C23 allows 64-bit enums now. >> A whole generation doesn't realise that there could possibly be any >> alternative, if you want a small-footprint systems language that can >> be implemented (if using tcc) in 180KB and that can build programs at >> 1Mlps (not much chance of such a compiler for Rust). > > Curious. Which generation is that, and why do they care about the > implementation footprint? I want top-class editors, compilers, linkers > and debugging tools like valgrind and gcc's -fsanitize=undefined option > for development. The current generation (the ones who are more likely to post on Reddit than usenet). It's easy to dismiss the size of a 100MB compiler as irrelevant (after all it's a minute or two of HD video or whatever), but 100MB for /a program/ still represents tremendous complexity and poor build times. (Such compilers are usually LLVM-based.) I've heard lots of horror stories of build times of minutes and even hours, even with not particularly high line counts. > There was a generation (mine) for whom 180KB for a compiler was out of > the question (unless you wanted to fuss about with overlays). We > accepted a very restricted notion of what a compiler could do as a > result. Having a small footprint compiler is still seen as a useful selling point, typically created by smaller teams or individuals. Having one as a single file is even better - copy that file to a USB stick and you /know/ you have everything needed to turn source code into binaries. > There is also a curious logical reason for C's popularity. There will > always be a most portable and most linkable language, and C was one of > the first candidates. Only Fortran came close, and if you think C is > quirky, try old Fortran. Thus C had a head start and so new platforms > had to have to have C to get all the portable code and libraries! So > the front runner gets further ahead. I spent a year writing Fortran IV. I could make it jump it through quite a few hoops, but I wouldn't rate it as a systems language. When the need for that first arose (for the Z80 systems I used to develop), my DIY solution took Algol68-like syntax together with the types and semantics that I as a hardware engineer and ASM user decided were most useful. Now most people think that that kind of lower-level language was single-handedly invented by C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-04 15:58 +0100 |
| Message-ID | <87wnajchko.fsf@bsb.me.uk> |
| In reply to | #167476 |
Bart <bc@freeuk.com> writes: > On 04/09/2022 14:17, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >>> Imagine transpiling from a language that implements it as you would >>> expect, into maintainable C code. (That is, not temporary code that is >>> only ever seen by a compiler; then you'd just write out actual >>> literals.) >>> >>> Which C features would you choose? Maybe 'limited' was apt after all. >> auto constexpr. > > So you'd represent a low level feature with simple, precise semantics > into a heavyweight, higher level one with a behaviour dependent on > crossing your fingers and hoping it all comes out alright. I'm not playing this game. You gave no details and yet I was foolish enough to answer. My mistake. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-04 18:00 +0100 |
| Message-ID | <tf2lje$10oa$1@gioia.aioe.org> |
| In reply to | #167477 |
On 04/09/2022 15:58, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> So you'd represent a low level feature with simple, precise semantics >> into a heavyweight, higher level one with a behaviour dependent on >> crossing your fingers and hoping it all comes out alright. > > I'm not playing this game. You gave no details and yet I was foolish > enough to answer. So was I. I spent time giving a considered answer which is just dismissed. If this Reddit I would just delete my comments. (For anyone else who may possibly be reading, I'd hope that using 'auto constexpr' to represent named compile-time expressions in a language being ported would clearly be seen to be non-optimum. BB need not answer.)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-09-04 19:26 +0200 |
| Message-ID | <tf2n4e$1nab$1@gioia.aioe.org> |
| In reply to | #167474 |
On 9/4/2022 3:17 PM, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 04/09/2022 00:19, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> On 03/09/2022 20:24, Ben Bacarisse wrote: >>>>> Bart <bc@freeuk.com> writes: >>>>> >>>>>> constexpr int = 123; # Can use & >>>>>> >>>>>> All with their own limitations, a few of which are highlighted. >>>>> Why is that a limitation? >>>> >>>> It's undesirable if you want proper separation between values and >>>> objects in a language. >>> Yes, it's undesirable (if you want that). I wondered why you thought it >>> was a /limitation/ -- i.e. that you had some use in mind that is ruled >>> out by the possibility of using &. >> >> Perhaps the wrong choice of word then; maybe 'hindrance' is better if >> looking for a way to express such a feature in C. >> >> Imagine transpiling from a language that implements it as you would >> expect, into maintainable C code. (That is, not temporary code that is >> only ever seen by a compiler; then you'd just write out actual >> literals.) >> >> Which C features would you choose? Maybe 'limited' was apt after all. > > auto constexpr. > > But if the maintainer of the code going to be the knuckle-dragging, > barely literate code monkey common to popular discussions of > maintainable code, I'd go with > > auto constexpr ... /* Turn on ALL compiler warnings and check each > message, twice. The overtime will be cheap given > your salary. */ > >>>> But I guess C doesn't care about that purity, and perhaps you don't >>>> either. >>> No one with even the slightest interest in purity looks to C. C's >>> phenomenal success is a constant embarrassment to anyone advocating for >>> pure language design. >> >> I feel, not embarrassment, but frustration when C is touted as being >> THE example of a language that is small, simple, clean (compared with >> C++!), explicit, close-to-the-metal, you know all the rest. > > I've never seen it touted like that. In the circles I moved in, it has > always been considered a dangerous language, particularly in the hands > of the inexperienced. It was seen as useful for portability (almost > nothing comes close) and for the fact almost everything else could link > to C libraries. When these mattered, my impression was the C was > chosen, rather reluctantly, and the coding given to the best people. > >> A whole generation doesn't realise that there could possibly be any >> alternative, if you want a small-footprint systems language that can >> be implemented (if using tcc) in 180KB and that can build programs at >> 1Mlps (not much chance of such a compiler for Rust). > > Curious. Which generation is that, and why do they care about the > implementation footprint? I want top-class editors, compilers, linkers > and debugging tools like valgrind and gcc's -fsanitize=undefined option > for development. > > There was a generation (mine) for whom 180KB for a compiler was out of > the question (unless you wanted to fuss about with overlays). We > accepted a very restricted notion of what a compiler could do as a > result. > >> I'm not saying an alternative ought to look like my product (which is >> a private tool anyway) but, yeah, you're right, it's embarrassing when >> the only such language that can be recommended is C. > > That's not what I said. The embarrassment I was referring to was that > of people who think that purity is (or should be) a winning feature. > Languages succeed for a very complex constellation of reasons, and the > elegance of the design does not rank very high. The is partly because > humans don't mind some linguistic complexity (compare English and > Esperanto) but it's mostly down to socio-economic factors. True (R.I.P. Pascal). However, I think that elegance of the design still has its place in success ranking. My first programming course was using Fortran (in favor of Pascal) because it was considered the most portable language in the engineering world. It was not until several years later that C was accepted as a replacement. The point is that, even if C is not an absolute 'pure' language, still it has good points in its design. Its memory model is quite solid even for today's standards, despite the fact of having been first designed in the '70s. If you don't want to call it elegance, call it effective design, or whatever. I still want to be skeptical about success being all about effective marketing. > > There is also a curious logical reason for C's popularity. There will > always be a most portable and most linkable language, and C was one of > the first candidates. Only Fortran came close, and if you think C is > quirky, try old Fortran. Thus C had a head start and so new platforms > had to have to have C to get all the portable code and libraries! So > the front runner gets further ahead. > As for what C is /today/ this is definitely an integral part of its nature. If we could rewind the tape of history 50 years back, but with today's knowledge of systems design, C would surely be different. Still, as for its "head start", I think C had some good of its own in it. Be as it may be, after so many years, any change has to face backwards compatibility and portability as the primary requirement. I think there's also another side of this story, although this is just an opinion. Since C code has been (and still is) so ubiquitous, hardware design has kept following that model - I'm thinking e.g. of the fact that most of the performance improvement has focused on speeding up the sequential execution model that is C is based upon. Multitasking has been introduced mostly as a replication of that same sequential unit - sharing data between threads is painful for hardware even today at the CPU level.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-09-03 16:24 +0000 |
| Message-ID | <tevv31$14fp$1@gioia.aioe.org> |
| In reply to | #167454 |
Bart <bc@freeuk.com> wrote:
> On 03/09/2022 02:23, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
> >> On 02/09/2022 18:37, antispam@math.uni.wroc.pl wrote:
> >>> Bart <bc@freeuk.com> wrote:
> >>>> On 31/08/2022 15:15, Ben Bacarisse wrote:
> >>>>> Bart <bc@freeuk.com> writes:
> >>>>>
> >>>>>> On 31/08/2022 13:48, Thiago Adams wrote:
> >>>>>
> >>>>>>> That is a simple "named constant" or I prefer a "named
> >>>>>>> literal".(string literal, number, compound)
> >>>>>>
> >>>>>> This is what I've been advocating here for years. But people seem to
> >>>>>> prefer using a combination of #define, enum, const.
> >>>>>
> >>>>> At least you put in a "seem". It seems that way to you, but it seems to
> >>>>> me that people use what C has, and to extrapolate from that to what they
> >>>>> would prefer is step too far.
> >>>>
> >>>> The subthread is partly about the introduction of 'constexpr'. So
> >>>> finally an opportunity to add what C has long lacked, but instead it's
> >>>> taken one of C++'s hairy features and just cut it down.
> >>>>
> >>>>>> They especially seem keen on 'const', which is a read-only attribute
> >>>>>> for variables.
> >>>>>
> >>>>> And you have a problem with that?
> >>>>
> >>>> Yes. You don't get named constants by emulating them with read-only
> >>>> variables, that's just crass. And it lets you do this:
> >>>>
> >>>> const int abc = 123;
> >>>> *(int*)&abc = 999;
> >>>>
> >>>> printf("abc = %d\n", abc);
> >>>>
> >>>> It tells me that 'abc' is 999; so much for being a named constant, or
> >>>> read-only!
> >>>
> >>> Hmm, this is inclomplete. Completing it to:
> >>>
> >>> const int abc = 123;
> >>>
> >>> #include <stdio.h>
> >>> int main(void) {
> >>> *(int*)&abc = 999;
> >>> printf("abc = %d\n", abc);
> >>> return 0;
> >>> }
> >>>
> >>> I get "Segmentation fault" trying to run it.
> >>>
> >>
> >> This all depends on matters outside the language itself.
> >>
> >> I get 999 with tcc. I get a crash with gcc.
> >>
> >> Moving abc inside the function, tcc still gives 999. gcc-O0 gives 999,
> >> other optimisations give 123.
> >
> > Inside functions things are easier, you can use 'register' to make
> > it nonaddressable:
> >
> > #include <stdio.h>
> > int main(void) {
> > register const int abc = 123;
>
> But this is still going around the houses. It makes the declaration even
> longer. It may potentially end up using a valuable register. It may end
> up using a non-volatile register that must be saved during calls. There
> may be a dozen such constants.
>
> It will need a heavyweight optimising compiler to avoid some of those
> disadvantages (and which will in turn take extra processing so longer
> compile-times and extra power).
>
> Compare with a feature like this:
>
> constant abc = 123;
>
> which has no such problems and can be handled by the simplest compiler.
Hmm, what your compiler generates given:
constant abc = 123*1000*1000*1000;
The resulting constant is bigger than 32-bits so you can not put
it as immediate in normal instruction. So you need to put it
somewhere (memory ???, register loaded by movabs ???). Even
simple compiler will not allocate memory to 'const' variable
with easy values as 123, but memory or register may be needed
in more complex cases.
Concerning 'constant', it looks like Wirth Pascal 'const'.
If you were Wirt and it was 1969-1977 you probably would
be satisfied with Pascal, apparently it did things
exactly like Wirth wanted them to be. But later Wirth
changes his mind and abandoned Pascal. And Pascal
users were dissatisfied with limitation on Pascal.
Turbo Pascal wanted initialized variables, so they
abuses variant of 'const' to create them. So in
Turbo Pascal one syntax of 'const' produced true
constant, while slightly different syntax gave
variables. Usere wanted non-scalar constants, so
Extended Pascal got typed constants and structured
initializers. Users wanted to pass aggregates
(constant or not) by reference, so there were several
parameter passing conventions beyond default call by
value and 'var' parameters. More generally, "constantness"
has many aspects:
- value may be computed at compile time (C 'const' and 'constexpr'
for global objects allow this)
- value may be used in places that need values at compile-time
(C 'constexpr')
- value is protected from modification in all/part of program
AFAICS C 'const' is mostly about third aspect, that is protecting
from modification. But due to C pointers it is not foolproof.
It helps detect/prevent uninteded modification, but determined
villain or a fool still can do harm.
> But the arguments I'm hearing are, Ah, but what about more complex
> objects, structs, arrays, compound literals, what about the one time in
> 1000 that taking the address might be conventient.
>
> OK, so forget introducing such a simple feature, and stick with the (IMO
> gross unsuitable) const and constexpr.
Well, for "simple feature", that is _globally_ defined constant
preprocessor is adequate, just
#define abc 123
'constant' feature is really needed for local use and more complex
cases.
>
> > *(int*)&abc = 999;
> > printf("abc = %d\n", abc);
> > return 0;
> > }
> >
> > gcc still only produces a warning, but you get warning without
> > any extra options.
> >
> >> The crash happens if 123 ends up being up into write-protected memory
> >> (so it doesn't get changed into 999, but it is still not satisfactory if
> >> that crashes an application and people lose their work or there are
> >> other consequences).
> >>
> >> But consider that some processors don't have write-protected memory,
> >> even if the compiler could make use of it.
> >>
> >> The point all along is that if a simpler named-value feature was used,
> >> all of the above becomes irrelevant. The program would fail to build in
> >> all cases even with the crappiest compiler.
> >
> > Create language that can handle better _all_ current uses of
> > C, then after say 20 years it can replace C. But now we have
> > to leave with effects of past decisions. And those decisions
> > were not entirely bad: one was able to create relatively simple
> > compiler that generated resonably fast code. And one could use
> > C for quite many problems.
>
> Introducing even a simple feature like 'constant' into standard C is a
> big deal. But it seems to have happened with 'constexpr'; why not do the
> other at the same time.
You probably should blame C++ for this. In C++ you have things
which need complex initialization, so must behave as variables
during initialization. But they may be logically constant
once initialized. Simple minded 'constant' would not do.
C do not want to diverge too far form C++, so that is why
'constexpr' was more appropriate than 'constant'.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-03 18:23 +0100 |
| Message-ID | <tf02io$o1d$1@gioia.aioe.org> |
| In reply to | #167461 |
On 03/09/2022 17:24, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> Compare with a feature like this:
>>
>> constant abc = 123;
>>
>> which has no such problems and can be handled by the simplest compiler.
>
> Hmm, what your compiler generates given:
>
> constant abc = 123*1000*1000*1000;
>
> The resulting constant is bigger than 32-bits so you can not put
> it as immediate in normal instruction. So you need to put it
> somewhere (memory ???, register loaded by movabs ???). Even
> simple compiler will not allocate memory to 'const' variable
> with easy values as 123, but memory or register may be needed
> in more complex cases.
It can happen that i64 immediates that need more than 32 bits are loaded
from memory (although that doesn't happen in my recent compilers for x64
for i64/u64 types, only for f32/f64).
But that memory is not accessible in user-code, it is a detail of
code-generation. You still can't assign or apply & because from the
language POV it is still only a value.
> Concerning 'constant', it looks like Wirth Pascal 'const'.
> If you were Wirt and it was 1969-1977 you probably would
> be satisfied with Pascal, apparently it did things
> exactly like Wirth wanted them to be. But later Wirth
> changes his mind and abandoned Pascal. And Pascal
> users were dissatisfied with limitation on Pascal.
> Turbo Pascal wanted initialized variables, so they
> abuses variant of 'const' to create them. So in
> Turbo Pascal one syntax of 'const' produced true
> constant, while slightly different syntax gave
> variables. Usere wanted non-scalar constants, so
> Extended Pascal got typed constants and structured
> initializers. Users wanted to pass aggregates
> (constant or not) by reference, so there were several
> parameter passing conventions beyond default call by
> value and 'var' parameters.
Yeah, my use of Pascal elsewhere wasn't a good example.
> More generally, "constantness"
> has many aspects:
> - value may be computed at compile time (C 'const' and 'constexpr'
> for global objects allow this)
> - value may be used in places that need values at compile-time
> (C 'constexpr')
> - value is protected from modification in all/part of program
>
> AFAICS C 'const' is mostly about third aspect, that is protecting
> from modification. But due to C pointers it is not foolproof.
> It helps detect/prevent uninteded modification, but determined
> villain or a fool still can do harm.
For me, CONST is specifically about evaluating things at compile-time,
even for my dynamic language.
Since the implementation language is lower-level, having complex
expression types for CONST, such as big-nums, is pointless because they
cannot be manipulated within the compiler (the relevant library exists
only at runtime).
So there is a grey area between CONST working on primitive numeric types
and strings, and VAR that are normal objects.
This doesn't bother me because I have other mechanisms I can use (from
using LET, to constructors generating immutable data).
It doesn't bother C either but because it doesn't care: Let's just use
CONST VAR for everything, even the simple stuff! Oh, we need a value for
SWITCH etc? Let's introduce CONST EXPR VAR!
>> OK, so forget introducing such a simple feature, and stick with the (IMO
>> gross unsuitable) const and constexpr.
>
> Well, for "simple feature", that is _globally_ defined constant
> preprocessor is adequate, just
>
> #define abc 123
I've listed all the problems with that in posts throughout the thread.
One is that you can't use 'abc' for any other purpose in the module.
So to me it is quite inadequate: having identifier scope that isn't even
beyond assembly code.
> 'constant' feature is really needed for local use and more complex
> cases.
Come on, even the lowliest assembler has 'constant':
abc = 123 ; CONST
def: dq 456 ; VAR
mov D0, abc ; load 123
mov D1, [def] ; load 456
So here, an assembler would have better such facilities than C!
> You probably should blame C++ for this.
I think this is part of the problem here: trying to narrow the gap a
little between C and C++.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-03 13:56 -0700 |
| Message-ID | <87k06kkwhx.fsf@nosuchdomain.example.com> |
| In reply to | #167454 |
Bart <bc@freeuk.com> writes:
[...]
> Introducing even a simple feature like 'constant' into standard C is a
> big deal. But it seems to have happened with 'constexpr'; why not do
> the other at the same time.
[...]
Quite likely because nobody proposed it.
Adding (a limited version of) `constexpr` was relatively easy to sell to
the committee. It already exists in C++, so there's plenty of existing
practice. It probably did require a fair amount of effort to write the
proposals and discuss them in the committee.
I personally like the `constant` feature I mentioned here recently, but
it doesn't do much that `constexpr` doesn't already do, and there's no
existing practice in C or C++.
Perhaps it would be easy for compilers to implement and test it -- more
precisely, for *every* compiler to implement and test it. It would
still have to be rigorously specified, something I didn't attempt to do.
Someone would have to write a proposal, which would have to be discussed
in committee meetings. There could be corner cases that I haven't
thought of. And so on.
The main advantage of my `constant` over `constexpr` is that `constant`
doesn't create an addressable object. Many would say that's not even an
advantage. And I can happily use `constexpr` in C (once it becomes
available) and just ignore the fact that, formally speaking, it created
an object.
On top of all that, there's the added burden in teaching the language
and the differences among "const", "constexpr", and "constant" -- plus
"consteval" and "constinit" if a future C adopts those from C++.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-31 06:52 -0700 |
| Message-ID | <cdefbb34-ba86-4813-b0de-adbea1713874n@googlegroups.com> |
| In reply to | #167366 |
On Wednesday, August 31, 2022 at 9:48:58 AM UTC-3, Thiago Adams wrote: ... > So C compilers now will have a much bigger compile time evaluator > that need to deal with floating point and also with compound literals. I am sure even without constexpr functions , only with expressions using ternary operator arrays etc.. constexpr opened the "metaprogramming" for C. Maybe it is Turing complete even without functions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 15:06 +0200 |
| Message-ID | <tenmc6$1qkrd$1@dont-email.me> |
| In reply to | #167364 |
On 31/08/2022 13:50, Thiago Adams wrote: > On Wednesday, August 31, 2022 at 5:45:10 AM UTC-3, David Brown wrote: >> On 31/08/2022 01:43, Bart wrote: >>> On 28/08/2022 23:46, David Brown wrote: >>>> On 28/08/2022 23:57, Thiago Adams wrote: >>>>> On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote: >>>>>> On 28/08/2022 21:31, Thiago Adams wrote: >>>>>>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: >>>>>>>> On 28/08/2022 15:11, Thiago Adams wrote: >>>>>>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: >>>>>>>> >>>>>>>>>> However, I would expect "constexpr" to be a relatively >>>>>>>>>> uncontroversial >>>>>>>>>> feature once people start to use it. >>>>>>>>> >>>>>>>>> >>>>>>>>> There are a lot of details about storage of constexpr. >>>>>>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf >>>>>>>>> >>>>>>>>> "NOTE An object declared in block scope with a storage-class >>>>>>>>> specifier constexpr and without static >>>>>>>>> has automatic storage duration, the identifier has no linkage, >>>>>>>>> and each instance of the object >>>>>>>>> has a unique address obtainable with & (if it is not declared >>>>>>>>> with the register specifier), if any. >>>>>>>>> Such an object in file scope has static storage duration, the >>>>>>>>> corresponding identifier >>>>>>>>> has internal linkage, and each translation unit that sees the >>>>>>>>> same textual definition implements >>>>>>>>> a separate object with a distinct address." >>>>>>>>> >>>>>>>> Do you see anything there you don't like, or which is not pretty >>>>>>>> obvious? >>>>>>> >>>>>>> I don't like constexpr mainly because it has storage and it is too >>>>>>> similar of const. >>>>>> Storage is up to the compiler. If the code can be compiled without any >>>>>> storage for the object, then no storage is needed. But you /can/ take >>>>>> the address of a constexpr object if you want. That would be very >>>>>> useful if you have, say, a function that takes a const pointer to a >>>>>> struct - you can pass it a constexpr struct if you like. >>>>> >>>>> I am very uncomfortable with "may" or "may not" have storage >>>>> specially in headers. >>>>> >>>> >>>> Do you have trouble with "static const" data? They are /exactly/ like >>>> constexpr data in this respect. >>>> >>>>> In C++, const is like that even before constexpr. >>>>> >>>>> I think other programmer are uncomfortable with that as well because >>>>> I don't remember to see c++ libs defining constants (using const) in >>>>> header files. >>>>> >>>> >>>> C++ headers do it all the time. If you want a constant value in a >>>> header, and it does not naturally form part of an enumeration, in C++ >>>> you just have "const int number = 123;" in the header (in effect, it >>>> is like "static const" in C). In more modern C++, you'd probably make >>>> it "constexpr", but many don't bother with that (often it makes no >>>> significant difference). > > I don't see people using "const int number = 123;" in C++ headers. > Do you use const in in headers? I don't. (C or C++) I do so regularly, if I need to "export" a fixed number from a module. (By "module", I mean a .c/.h or .cpp/.h pair, occasionally with other files, rather than a C++20 module.) And since much of my work is embedded systems, fixed numbers turn up often. So I might have a module that supports analogue inputs, and in the header there could be constants for the number of analogue inputs supported, the full-scale range in "raw" units, scale factors for converting to floating point voltages, etc. Many of these would be "const", either "const int", "const double", or whatever is appropriate. For C++ since C++11, I'd usually use "constexpr" rather than "const". And in C, I'd use "static const" - unless the number was also useful for array sizes, when I would fall back to "enum" or "#define" due to the limits of C. (Obviously I also use "enum" for real enumerations.) When I move to C23, I'll move to "constexpr" there too. I used more #define constants in older times, especially with some weaker compilers that had very limited optimisations. There are typically not a large number of such constants in my headers - I generally don't need to export many constant values like that (excluding real enumerations). Different programmers do things in different ways - I can't answer for the code you see. If you are looking at popular open-source projects, however, it's not uncommon for these to be designed to work with a wide range of compilers and options spanning very different levels of optimisation and support for standards, as well as code with a history stretching far back in time. I have far tighter control of my tools and the scope of my work, so I am freer to take advantage of modern techniques with quality tools. > > I think more programmers have the same feeling of > "I am creating a variable read-only" that may or may not be true. > When you define a variable as "const" you /are/ making a read-only variable. If you attempt to change its value in some way (such as using pointers with explicit conversions to remove the "const"), you can expect to get a program crash if you are lucky, or random undefined behaviour if you are less lucky. And if you are using even a half-decent compiler, you can expect that the variable itself will disappear unless it is really necessary.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 12:50 +0100 |
| Message-ID | <tenhu2$91s$1@gioia.aioe.org> |
| In reply to | #167360 |
On 31/08/2022 09:44, David Brown wrote:
> On 31/08/2022 01:43, Bart wrote:
>> Your comments point to this behaviour:
>>
>> const int abc; // C: always exports
>> const int abc; // C++: never exports
>> static const int abc; // C: never exports
>>
>> This does not inspire confidence!
>
> static const int abc = 123; // Always internal linkage
> extern const int def = 456; // Always external linkage
>
> const int x = 123; // "static" in C++, "extern" in C.
>
> If you need confidence, learn the rules - look for patterns and
> reasoning, rather than assuming everything is flawed. You are not
> stupid - stop pretending this is too complicated for you.
It /is/ flawed. You mention elsewhere that you don't consider PL design
as 'art'; I can believe that if you think so highly of C++.
I think that aesthetics plays an important part, and being clean, tidy,
orthogonal can help.
I know you completely disregard examples from my own work, but there
must be examples from other languages where you can define these two
classes of named entities:
Named value Always a compile-time value, can be defined
in terms of other named values, never takes
up accessible storage for scalar types, you
can't take its address, IMPOSSIBLE to modify
Named variable Can hold a run-time value, uses storage,
even if nominal, can have address taken,
can be read-only with 'const'
Both of them are generally not exported, unless you explicitly do so,
say using that `extern` from C++ (silly a name as it is, as it suggests
import not export!).
I would say such a scheme is simpler than anything in C or C++.
(Here is how I believe it works in Algol 68:
int abc = 123; # named value
int def := 123; # named variable
There, the /name/ `abc` has type `int'; the name `def` has type `ref
int`. I think this aspect of it is confusing, even if common to every
HLL; in C:
123 has type int
def The 'name', that is `&def` in C, has type int*
The important thing is that a 'variable' has one extra level of
indirection in its type, compared with a named value or constant.
The syntax difference in Algol 68 is subtle; in my syntax, it's more
explicit.)
> For people who are willing to learn the languages they use or discuss,
> "constexpr" is a useful feature that adds to the language. For people
> who would rather focus on how they think things are complicated, or make
> excuses for their own misunderstandings, "constexpr" is yet another
> feature to complain about. It's fine if you don't like C, or don't want
> to use C, or prefer other languages, or find C hard to learn. But if
> you are not ready to learn the language or a feature of it, and to
> understand why it is in the language and what use people make of it,
> then you give up your right to express an informed opinion that people
> should take seriously. You are left with your right to an uninformed
> opinion that people will often ignore. (Or, for a while at least,
> people may try to inform you and correct you.)
I don't need people to tell me when something is a mess, and when a new
feature both tries to mitigate that mess, and makes it worse.
If that new feature (constexpr) was designed to completely replaced
existing use-cases for #define, enum, const in attempting to create
named-values, then at least that would have been something, but it doesn't.
It's just a version of the current 'const int abc=123' which is allowed
to be used as a compile-time constant, yet `abc` remains a variable with
the same characteristics as any other variable.
[toc] | [prev] | [next] | [standalone]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web