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 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-15 17:29 -0700 |
| Message-ID | <86zgf0kvpr.fsf@linuxsc.com> |
| In reply to | #167727 |
Kaz Kylheku <480-992-1380@kylheku.com> writes: > On 2022-09-14, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Kaz Kylheku <480-992-1380@kylheku.com> writes: >> >>> On 2022-09-13, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> On 12/09/2022 05:22, Tim Rentsch wrote: >>>>> >>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>>>> >>>>>>> Thinking about it a bit more, the common factor with all literals is >>>>>>> that they represent /anonymous/ values. Without compound literals you >>>>>>> could not write a value of any aggregate type, other than char[]. >>>>>> >>>>>> The key difference is that "constants" are values, and "literals" >>>>>> are objects. >>>>> >>>>> So a literal like 726163 is an object, and not a value? >>>> >>>> As far as ISO C is concerned, the token '726163' is a constant, >>>> not a literal, and is a value rather than an object. >>> >>> The term "literal" in computer science is a shortening of >>> "literal constant". (There are also symbolic/manifest constants.) >> >> I am not aware of any authoritative reference that defines the >> term "literal" for the field of computer science. > > The Oxford Dictionary of Computer Science (7th ed, 2016) has an entry: > > literal > > A word or symbol in a program that stands for itself rather than as a > name for something else, i.e. an object whose value is determined by > its denotation. Numbers are literals; if other symbols are used as > literals it is necessary to use some form of quoting mechanism to > distinguish them from variables [...] The word "constant" has been used in mathematics for more than 100 years before programming languages existed.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-19 02:33 +0000 |
| Message-ID | <20220918193024.619@kylheku.com> |
| In reply to | #167736 |
On 2022-09-16, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > The word "constant" has been used in mathematics for more > than 100 years before programming languages existed. Good observation; but so has "literal". -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-11 21:07 -0700 |
| Message-ID | <86r10hp767.fsf@linuxsc.com> |
| In reply to | #167439 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> On Friday, September 2, 2022 at 1:53:06 PM UTC-3, Bart wrote:
>>
>>> On 02/09/2022 16:19, Ben Bacarisse wrote:
>>>
>>>> Bart <b...@freeuk.com> writes:
>>>>
>>>>>>> The only other actual literal is a string.
>>>>>>
>>>>>> How about compound literals?
>>>>>
>>>>> The 'literal' in those is just a term somebody decided use.
>>>>
>>>> They are literals because they describe a specific value in the source
>>>> code. The value is "literally" in the source.
>>>>
>>>>> (Elsewhere I would call them constructors.)
>>>>
>>>> Sure. And the ASCII digit 1 is a constructor for an int value. And a "
>>>> optionally followed by characters and another " is a constructor for a
>>>> char array object.
>>>>
>>>> Both terms work, but the one C has chosen is "literal".
>>>
>>> Some constructors are special:
>>>
>>> 123456
>>> 123.456
>>> "abcdef"
>>> 'A'
>>>
>>> because they can /only/ comprise values known at compile-time. These I
>>> like to call literals.
>>
>> Compound literals also are values known at compile time.
>
> They /may/ be but they don't have to be (except at file scope). And yet
> the syntax is still called a compound literal.
Even at file scope the values might not be known at compile time.
For example, in this code
extern int x;
void **foo = &(void*){ &x };
the value '&x' is not known until link time.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-02 11:03 -0700 |
| Message-ID | <87fsh9hcx6.fsf@nosuchdomain.example.com> |
| In reply to | #167430 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
>
>>>> The only other actual literal is a string.
>>> How about compound literals?
>>
>> The 'literal' in those is just a term somebody decided use.
>
> They are literals because they describe a specific value in the source
> code. The value is "literally" in the source.
To be fair, using the term "literal" for something that might be
computed during execution is a bit odd -- but it's not a huge problem.
C doesn't have "literal" as a syntactic category. It has
"string-literal" and "compound-literal". Numeric constants are called
"constants", not "literals".
(C++ does refer to what C calls "constants" as "literals". It doesn't
have compound-literals, but it does have user-defined-literals, whose
values may be computed during execution. Personally I prefer C++'s
terminology.)
It might have been nice if the term "literal" had been reserved for
things whose values are fully expressed in the source, but again, it's
not a huge problem. If I wanted a semantically and notationally pure
language with crystal clear terminology, I'd look elsewhere than either
C or 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-02 20:47 +0100 |
| Message-ID | <87k06lh831.fsf@bsb.me.uk> |
| In reply to | #167436 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Bart <bc@freeuk.com> writes: >> >>>>> The only other actual literal is a string. >>>> How about compound literals? >>> >>> The 'literal' in those is just a term somebody decided use. >> >> They are literals because they describe a specific value in the source >> code. The value is "literally" in the source. > > To be fair, using the term "literal" for something that might be > computed during execution is a bit odd -- but it's not a huge problem. Yes, Bart has a point. I wonder if the proposal started out as a being limited to compile-time constant values. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-02 15:52 +0200 |
| Message-ID | <tet1q8$2hqoe$1@dont-email.me> |
| In reply to | #167424 |
On 02/09/2022 14:24, Bart wrote: > On 02/09/2022 08:30, David Brown wrote: >> It is not easy to come up with a "perfect" solution for handling >> constants and/or read-only access. It's even harder when retrofitting >> it to an existing language. >> > > It looks like everybody is now agreeing that dedicated solutions for > named literals are preferable, separate from that mess of > const/constexpr with all their dangers. > No, it does not look like "everybody" is doing anything at all. Please stop extrapolating "one person" to "everyone", "most people", "the majority of this group", and all your other absurd exaggerations. When one person says something, it means /one/ person has that opinion. Two people holding somewhat similar ideas is stronger than one, but it is still a world apart from making claims about "everybody". In case it is still not clear to you, I speak for /me/ - I don't speak for the "C community", or "gcc users", or whatever else you might be imagining. And despite the very high regard held by many in this group for Keith and Ben, the same applies to their opinions. You also need to understand that people can think that an aspect of C is good enough, or works fine in practice, while also thinking that an additional feature or change would improve it. A language is not "broken" or "flawed" even if more than one person thinks a particular change would be a good idea. People can also think "it would have been nice if C had done /this/, but we know that change cannot be made", or "if we were designing a new language from scratch, we'd do it differently". About the only thing I believe a majority of C programmers would agree on in this discussion, is that the current (with or without C23 constexpr) situation for variables, constants and read-only protection is not as neat, consistent, safe or flexible as it could have been had it been designed /now/ as part of a modern language design, rather than evolving over five decades or so. > Even I didn't go as far as criticising the half-hearted 'enum' solution > for its syntax, but it looks like you see the problem there too. > I'm not keen on "ugly" coding, no. > The solutions for integers, floats and to a smaller extent pointers > (since compile-time values are rare) are easy, especially if you think > of this applying only to literals. > > The only other actual literal is a string. It is true that these types of literals are constants are common. But I am not keen on a solution that is arbitrarily limited like that. A feature that only works for a limited selection of the types available is a waste of time as far as I am concerned. Part of the reason why "constexpr" was needed is that "enum" only works for int (or now with C23, any integer type). > > > and/or > > No, read-only control is a separate aspect that applied to variables > that use nominal storage. > > > It's even harder when retrofitting > > it to an existing language. > > The only hard thing is introducing a new keyword, but that has somehow > been managed for 'constexpr'. And here, working out where string > literals fit in as they come between the two kinds of entities. > I think you have spent far too much time with your personal language to have any understanding what is "hard" when it comes to changing a language like C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-02 16:01 +0100 |
| Message-ID | <tet5s2$1n78$1@gioia.aioe.org> |
| In reply to | #167426 |
On 02/09/2022 14:52, David Brown wrote:
> On 02/09/2022 14:24, Bart wrote:
>> On 02/09/2022 08:30, David Brown wrote:
>
>>> It is not easy to come up with a "perfect" solution for handling
>>> constants and/or read-only access. It's even harder when
>>> retrofitting it to an existing language.
>>>
>>
>> It looks like everybody is now agreeing that dedicated solutions for
>> named literals are preferable, separate from that mess of
>> const/constexpr with all their dangers.
>>
>
> No, it does not look like "everybody" is doing anything at all. Please
> stop extrapolating "one person" to "everyone", "most people",
Of /the participants in this thread/, two already seemed in favour of
such a feature, and then Keith and now you have said you like 'constant'.
>> The only other actual literal is a string.
>
> It is true that these types of literals are constants are common. But I
> am not keen on a solution that is arbitrarily limited like that. A
> feature that only works for a limited selection of the types available
> is a waste of time as far as I am concerned.
C itself is limited like that. What types can it can manipulate by
value? What types can usefully have values known and manipulated at
compile-time?
The 'constant' feature that some advocate is specifically for values.
As an example of how it might work for a language that is not C, C++,
Algol 68, or one of mine, then Pascal's 'Const' works for these types only:
- Ordinal types [integers and enumerations]
- Set types
- Pointer types (but the only allowed value is Nil).
- Real types [floats]
- Char
- String
If you aim to apply 'constant' to every conceivable type, then it's not
going to work. The feature will never get implemented, there will not be
enough distinction between 'constant' and 'const/constexpr' for
elaborate types to make it worthwhile.
Result: there are will never be a dedicated feature for named literals
of arbitrary integer and float types, which accounts for 99% of use-cases.
It's not only C's loss, but everyone's because there's going to be more
unsafe buggy code about than otherwise. Or even if everyone is going to
be as conscientious as you, a lot more effort has to be spent getting it
right than otherwise.
ave spent far too much time with your personal language to
> have any understanding what is "hard" when it comes to changing a
> language like C.
I've mentioned a couple of times that I've partially implemented
'constant' in C. I didn't do so fully because there was no point (I have
all the named literals I want in my own languages). It was just a proof
of concept.
I didn't see any particular difficulties:
constant T X = Expr;
Expr is evaluated once by the compiler into value Y, which needs to be a
value known at compile, coerced to type T as needed.
Wherever that X is encountered within the program, then it is treated as
though value Y had been written. There are these differences compared
with just repeating Expr at each instance, or using a macro alias for Expr:
* Any names used are those in scope when X was defined
* Any constant reduction is done once
* When Y comprises a value that requires storage, then each instance can
use the same memory
These apply to using const/constexpr too, so the further differences
from those are:
* Values can be used as compile-time expressions (in the case of 'const')
* Assignment to X is not allowed at all (not just because it has type
const T rather than T, but because it's meaningless; you can't assign to
a value)
* Address-of can't be applied (not because it uses no storage - it might
do - but again because Y is considered a /value/, regardless of what
might be necessary behind the scenes).
Again to emphasise:
'constant' defines a named VALUE with no accessible storage
'const/constexpr' defined a named OBJECT with accessible storage
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-02 19:22 +0200 |
| Message-ID | <tete4i$2j59a$1@dont-email.me> |
| In reply to | #167429 |
On 02/09/2022 17:01, Bart wrote:
> On 02/09/2022 14:52, David Brown wrote:
>> On 02/09/2022 14:24, Bart wrote:
>>> On 02/09/2022 08:30, David Brown wrote:
>>
>>>> It is not easy to come up with a "perfect" solution for handling
>>>> constants and/or read-only access. It's even harder when
>>>> retrofitting it to an existing language.
>>>>
>>>
>>> It looks like everybody is now agreeing that dedicated solutions for
>>> named literals are preferable, separate from that mess of
>>> const/constexpr with all their dangers.
>>>
>>
>> No, it does not look like "everybody" is doing anything at all.
>> Please stop extrapolating "one person" to "everyone", "most people",
>
> Of /the participants in this thread/, two already seemed in favour of
> such a feature, and then Keith and now you have said you like 'constant'.
>
Even within this thread, two people is not "everybody". If you mean
"two people", say "two people". Or "some people", or "at least a few
people" - say something that is not a ridiculous exaggeration and
extrapolation.
And what I said is that I prefer Keith's "constant" to expanding "enum"
to have the effect he described. In a parallel universe where C was
very different, "constant" would be a good feature. I am not convinced
that it would be a good idea to add it to C as it stands in C23 with
"constexpr" - it would IMHO give too little, while doing nothing that
can't be handled by "constexpr". It would not replace "constexpr",
which would still be needed for bigger constants, and would be a
gratuitous difference from existing C++.
>>> The only other actual literal is a string.
>>
>> It is true that these types of literals are constants are common. But
>> I am not keen on a solution that is arbitrarily limited like that. A
>> feature that only works for a limited selection of the types available
>> is a waste of time as far as I am concerned.
>
> C itself is limited like that. What types can it can manipulate by
> value? What types can usefully have values known and manipulated at
> compile-time?
Compound literals are literal values of types such as arrays and
structs. C23 "constexpr" lets you create and use arrays and structs at
compile-time, as literal values. Structs can be manipulated as values
in many ways:
typedef struct { int rl; int im; } gaussian_int;
gaussian_int gaussian_add(gaussian_int x, gaussian_int y) {
gaussian_int z;
z.rl = x.rl + y.rl;
z.im = x.im + y.im;
return z;
}
typedef struct { gaussian_int vect[4]; } gaussian_vect;
gaussian_vect gaussian_vect_add(gaussian_vect xs, gaussian_vect ys) {
gaussian_vect zs;
for (int i = 0; i < 4; i++) {
zs.vect[i] = gaussian_add(xs.vect[i], ys.vect[i]);
}
return zs;
}
That passes a struct of an array of structs around as a value type.
>
> The 'constant' feature that some advocate is specifically for values.
>
> As an example of how it might work for a language that is not C, C++,
> Algol 68, or one of mine, then Pascal's 'Const' works for these types only:
>
> - Ordinal types [integers and enumerations]
>
> - Set types
>
> - Pointer types (but the only allowed value is Nil).
>
> - Real types [floats]
>
> - Char
>
> - String
The original Pascal was so hopelessly limited that it quickly became
outdated for any practical use, and was replaced in reality by much more
flexible and powerful dialects and variations. Real Pascal systems
support constants of any type :
<https://wiki.freepascal.org/Basic_Pascal_Tutorial/Chapter_1/Constants>
Whether or not you consider that an argument for constants of any type
in C, is up to you - after all, there are a great many differences
between C and Pascal, and Pascal is not considered a major influence on
modern C.
>
> If you aim to apply 'constant' to every conceivable type, then it's not
> going to work. The feature will never get implemented, there will not be
> enough distinction between 'constant' and 'const/constexpr' for
> elaborate types to make it worthwhile.
Um, yes, it /will/ work - C23 has "constexpr" that will work for any
type. (OK, it's going to look really messy for data structures built up
with pointers.)
>
> Result: there are will never be a dedicated feature for named literals
> of arbitrary integer and float types, which accounts for 99% of use-cases.
>
> It's not only C's loss, but everyone's because there's going to be more
> unsafe buggy code about than otherwise. Or even if everyone is going to
> be as conscientious as you, a lot more effort has to be spent getting it
> right than otherwise.
There are basically two reasons for buggy code (assuming the
specification is correct in the first place). One is code written by
people who don't know what they are doing, or don't bother to do it
right - they use poor quality tools (or fail to use good tools
properly), they use poor development processes (such as failing to test
code), they don't know the language well, they haven't been trained
appropriately, etc.
There is /nothing/ a language can do to have these people write correct
code. It is possible for a language to limit the damage, or catch more
errors at run-time - but that comes at a significant cost to run-time
efficiency, and is not appropriate for a high-efficiency language like
C. (Let these folks stick to Python, or C#, or some other managed
language.) There are things a language design can do to make the risk
higher for such coders - and C undoubtedly has its fair share of those
(there's no need to list them). Adding a feature like "constexpr" to C
will in no way make things worse for such coders - they are unlikely
even to learn of its existence.
The other other reason for bugs is mistakes made despite a programmer's
best efforts to learn the language and tools, and code carefully. That
is why I have lots of warnings enabled for gcc - if I make a silly
mistake but the compiler catches it, it is easier, faster and cheaper to
fix than during testing stages. "constexpr" reduces the risk of such
mistakes because the programmer and the compiler can see more things
fixed at compile-time rather than only known and tested at run-time -
the programmer can add more "static_assert" statements instead of
run-time "asserts" that may never be checked. It does not add to the
risk of mistakes despite being able to take the address of the constexpr
object, because the alternative would have been the same mistake with a
non-constexpr object.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-02 10:50 -0700 |
| Message-ID | <87k06lhdhb.fsf@nosuchdomain.example.com> |
| In reply to | #167424 |
Bart <bc@freeuk.com> writes:
> On 02/09/2022 08:30, David Brown wrote:
>> On 02/09/2022 00:10, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> It is important that you can take the address of constexpr objects (as
>>>> a pointer-to-const) - not just for using arrays, but for any time you
>>>> want to pass around the object by reference.
>>>
>>> I wouldn't go that far.
>> OK - I think it is sometimes convenient to be able to take their
>> address, and important that constexpr is consistent. In particular,
>> if you can take the address of a constexpr array, which we must be
>> able to in order to use the array, then I believe it is much better
>> to allow taking the address of /all/ constexpr objects rather than a
>> complicated system of special case rules.
>> There is one thing I would have preferred, however - I would have
>> liked the standard to say that the addresses of constexpr, their
>> uniqueness, overlapping, and consistency across translation units to
>> be unspecified. In other words, if you have "constexpr char text[]
>> = "Hello, world!"; " in a header, then it is up to the
>> implementation to say whether different uses in different units have
>> the same address or a different address. I'd expect a smarter
>> linker to merge them, and a simpler linker to have them separate.
>> I'd even want to allow "constexpr char world[] = "world!";" to
>> overlap, though that would require a very smart linker.
>>
>>> I don't think it's particularly important for
>>> constexpr-defined objects to have addresses. Indeed, I would have liked
>>> to have a feature that replaces and extends the enum hack:
>>> enum { answer = 42 };
>>> which makes `answer` a constant and a constant expression (and *not* the
>>> name of an object) with type int and value 42. C23 even extends enum to
>>> let you specify the underlying type, so you could use the enum hack for
>>> any integer type (but not for floating-point).
>>>
>> The disadvantage of the "enum hack" is that it looks and reads like
>> a hack :
>> enum : long int { answer = 42 };
>> I'd prefer your suggested "constant" keyword, even if it duplicates
>> functionality, because it gives clearer code.
>>
>>> Having constexpr-defined identifiers be the names of objects with
>>> addresses, particularly for scalar types, is in my opinion an annoyance.
>>> It can certainly be useful when you happen to need a pointer to const
>>> whatever, but I don't think that's a common requirement. Something like
>>> the "constant" feature I suggested elsewhere in this thread:
>>> constant int answer = 42;
>>> would have been IMHO much cleaner. And the fact that
>>> constexpr int answer = 42;
>>> makes `answer` a constant expression *and* at least notionally gives it
>>> a memory address can cause real problems if you're not careful.
>>>
>>> My ideal solution would have been something like:
>>>
>>> - const means read-only, and nothing else. const-qualifying something
>>> does not make it a constant expression.
>>>
>>> - constant means compile-time constant. A constant-defined identifier
>>> is a constant expression with no associated storage, similar to an
>>> enum constant. The initializer must be a constant expression.
>>>
>>> Something like constexpr could still be useful for arrays, which still
>>> have to be addressable objects.
>>>
>>> Having said all that, there are always tradeoffs. The fact that
>>> constexpr objects have addresses is only a minor annoyance, in a
>>> "Doctor, it hurts when I do this" sense. The potential problems are
>>> unlikely to occur unless you deliberately do a pointer cast, which any C
>>> programmer should know is a sharp and dangerous tool (something that
>>> bart would be well advised to mention when he brings it up rather than
>>> pretending to be surprised every time he rediscovers the damage it can
>>> be used to do).
>>>
>> It is not easy to come up with a "perfect" solution for handling
>> constants and/or read-only access. It's even harder when
>> retrofitting it to an existing language.
>
> It looks like everybody is now agreeing that dedicated solutions for
> named literals are preferable, separate from that mess of
> const/constexpr with all their dangers.
You overstate my level of agreement.
It's too late to add major new features to C23. I'm satisfied with
constexpr as it will appear in C23, even though presents has some minor
annoyances. I've suggested a new feature for named constant
expressions, discussing how I'd like it to appear *if* it were added to
the language. I haven't advocated adding it. (I've also discussed what
I'd like to see if backward compatibility were not a concern -- but of
course it is.)
If I were proposing changes to C earlier in the process, I might
advocate my `constant` feature. I wouldn't mind seeing it in C26 or
C29, but the addition of constexpr in C23 makes that less likely to
happen, since constexpr already covers most of the functionality.
(Explaining const is hard enough. Explaining const, constexpr, and
constant would be even harder.)
I have not understated the difficulty of adding new features to the
language, nor have I repeatedly expressed astonishment every time I
rediscover that it's possible to write bad code in C.
> Even I didn't go as far as criticising the half-hearted 'enum'
> solution for its syntax, but it looks like you see the problem there
> too.
>
> The solutions for integers, floats and to a smaller extent pointers
> (since compile-time values are rare) are easy, especially if you think
> of this applying only to literals.
>
> The only other actual literal is a string.
constexpr makes sense for structs and unions -- and given that constexpr
objects have addresses, it also makes sense for arrays (not just
strings).
This is valid in C++, and I believe in C23:
constexpr struct { int a; double b; char c[6]; } ce
= { 42, 1.5, "hello" };
and makes ce.a and ce.c[0] constant expressions.
[...]
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-01 00:30 +0100 |
| Message-ID | <teoqvb$1c8$1@gioia.aioe.org> |
| In reply to | #167402 |
On 31/08/2022 21:01, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> If you want to be able to take the address of a literal, such as 123,
>> then I can understand that, even if I don't agree with it.
>>
>> /Then/ I can see why you'd want the same ability with named literals.
>>
>> (If I was implementing it, it wouldn't be /the/ value 123, but of some
>> dummy location into which a copy of 123 was put.)
>>
>> But if you can't take the address of 123, then why would you want to
>> do so of a named alias of it?
>
> constexpr objects aren't just of scalar types.
>
> At least in C++, you can have a constexpr array (I think it's the same
> in C23 but I haven't checked):
>
> constexpr int arr[] = { 10, 20, 30 };
>
> If an array doesn't have an address, you can't even index it.
>
> I do like the idea of being able to associate a name with a constant
> expression without implicitly assigning storage to an object associated
> with that name. And maybe that's what "constexpr" should have been --
> but then you couldn't have constexpr arrays. It would have required
> another special case.
>
> Even for scalars, constexpr lets you get an address of type
> `const scalar_type*`, and sometimes that's what you need.
>
> constexpr isn't perfect, but it's good enough, and it's better than what
> C has now. And as always, C doesn't prevent you from writing bad code,
> for example using a pointer cast to modify a read-only object.
>
> If I were to suggest a new feature, I might propose a "constant"
> keyword:
>
> constant int n = 42;
>
> where n would be a constant expression with type int and value 42 *and
> no address*. I'm not sure such a feature would be worthwhile.
'constant' is what I used for an experiment in my bcc product:
* It's only implemented at file scope (C declaration and type grammar
makes such experiments awkward)
* It introduces a new category of name
* & address-of is not allowed on a constant name, and it cannot be used
on LHS of an assignment
* It does not use storage, as far as the language is concerned
* It can be applied to integer and float types, but nothing else (which
accounts for 99% of intended uses)
* It can be used for non-VLA bounds, and switch-case values, and
expressions using those can be reduced; results are always compile-time
constants, which can be used for static data initialisers.
In short, it ticks nearly all the boxes in my table (it fails on only
working for ints and floats).
As for being worthwhile, my test involved adding perhaps a couple of
dozen lines of code, for something that could be a practical alternative
to 'enum', but not limited to 'int' values, and not needing that special
brace syntax; it would look just like your example.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-31 21:35 +0100 |
| Message-ID | <87mtbknobb.fsf@bsb.me.uk> |
| In reply to | #167395 |
David Brown <david.brown@hesbynett.no> writes: > I still can't understand why he wants it to be impossible to take the > address of a named constant, however. Presumably because it's internally consistent with how thing work in his own language. The argument being that things like 'X' and 42 are not lvalues, so why should they become lvalues just because they get a name? He is, I think, heavily influence by Algol 68, and in Algol 68 identifiers are always just bound to what we'd call rvalues: INT x = 42; makes x stand for 42 but with all the associated type information, scope rules and so on. You can't assign to x or get it's address any more than you could for 42. To get a variable, you bind the identifier to a value that refers to a memory location: REF INT v = LOC INT := 42; (LOC means local -- AKA automatic storage duration -- and the assignment expression is optional.) This is so common that there's a shorthand: INT v := 42; It's all very consistent and not much like modern C. What Algol 68 lacks (amongst other things) is a way to bind an identifier to a read-only location. It's just not in the model. Maybe that's partly why bartc sees no need for it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-01 10:14 +0200 |
| Message-ID | <teppl3$24csf$1@dont-email.me> |
| In reply to | #167403 |
On 31/08/2022 22:35, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> I still can't understand why he wants it to be impossible to take the
>> address of a named constant, however.
>
> Presumably because it's internally consistent with how thing work in his
> own language. The argument being that things like 'X' and 42 are not
> lvalues, so why should they become lvalues just because they get a name?
>
> He is, I think, heavily influence by Algol 68, and in Algol 68
> identifiers are always just bound to what we'd call rvalues:
>
> INT x = 42;
>
> makes x stand for 42 but with all the associated type information, scope
> rules and so on. You can't assign to x or get it's address any more
> than you could for 42.
>
> To get a variable, you bind the identifier to a value that refers to a
> memory location:
>
> REF INT v = LOC INT := 42;
>
> (LOC means local -- AKA automatic storage duration -- and the assignment
> expression is optional.) This is so common that there's a shorthand:
>
> INT v := 42;
>
> It's all very consistent and not much like modern C.
>
> What Algol 68 lacks (amongst other things) is a way to bind an
> identifier to a read-only location. It's just not in the model. Maybe
> that's partly why bartc sees no need for it.
>
Thanks for that explanation - Algol was a bit before my time. That is,
as you say, a somewhat different model than C's. There are plenty of
languages where the norm is that an identifier refers to a single value
(either compile-time, or run-time) rather than being a variable.
One of my favourites for constant initialisation has to be MetaFont (or
MetaPost). It lets you write things like :
a + b = 3;
2a - 1 = b + 2;
That defines "a" to be 2 and "b" to be 1.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-30 07:58 -0700 |
| Message-ID | <b553bb48-a8c7-4819-8aac-1d21d7b0cd96n@googlegroups.com> |
| In reply to | #167332 |
On Tuesday, August 30, 2022 at 10:58:29 AM UTC-3, Bart wrote:
> On 30/08/2022 12:15, David Brown wrote:
> > On 30/08/2022 02:51, bart c wrote:
>
> > (Being C++, this is really off-topic for c.l.c., but it might be of
> > interest to people here.)
> >
> >
> > In C++, you can write at file scope :
> >
> > int fib(int a) {
> > if (a < 2) return 1;
> > return fib(a - 1) + fib(a - 2);
> > }
> >
> >
> > int x = fib(5);
> > int y = fib(40);
> >
> >
> > The compiler may choose, as an optimisation, to pre-compute "fib(5)" and
> > use constant initialisation equivalent to "int x = 8;", so that the
> > memory for the variable "x" gets loaded with the value 8 before main()
> > or any other "real" code of the program runs. (You are familiar with
> > this initialisation procedure from C.)
> >
> > But for y, and optionally for x, the compiler will use run-time
> > initialisation. In effect, it generates "int y;" and a code section
> > that executes "y = fib(40);" and is run pre-main.
> >
> > Sometimes you don't want the possibility of having such run-time
> > initialisation, with all its potential complications such as startup
> > time, initialisation order, protection against race conditions for
> > function-local statics called from multiple threads, etc. But given the
> > code above, you cannot easily tell which, if either, of the variable
> > initialisations is done with a simple constant copy.
> >
> > To solve this, you first have to add "constexpr" to the "fib" function.
> > That tells the compiler that if it is given a constant expression
> > argument, the function can be evaluated at compile time to give a
> > constant expression result (while also still being usable at runtime -
> > "consteval" is the alternative to say that the function is compile-time
> > only and can never be used at runtime). This places certain
> > restrictions on the function - it has to be "pure", at least for the
> > particular constant values that you use in the program, but that's fine
> > here.
> >
> > Next, you label the variables as "constinit". This tells the compiler
> > that these functions must be initialised as constants, or compilation
> > will fail :
> >
> > constexpr int fib(int a) {
> > if (a < 2) return 1;
> > return fib(a - 1) + fib(a - 2);
> > }
> >
> > constinit int x = fib(5);
> > constinit int y = fib(40);
> >
> >
> > Now the compiler has no choice but to treat this as "int x = 8;" and
> > "int y = 165580141;". If the compiler can't do the calculation at
> > compile time (such as if I'd written fib(46), which at 2971215073
> > overflows a 32-bit int, or fib(41) which exceeds gcc's standard limit of
> > the number of steps it allows in a compile-time execution), then the
> > compiler halts with an error.
> >
> >
> > So "constinit" gives you tighter control of such initialisation. Note
> > that the variables "x" and "y" are still variables - it is only the
> > initialisation that is done by a constant, they are not constants
> > themselves (as they would be with "constexpr int x = fib(5);". Indeed,
> > the line "constinit int x = fib(5);" is equivalent to :
> >
> > constexpr int x_init = fib(5);
> > int x = x_init;
> OK, thanks.
>
> So 'constinit' means something should be evaluated before execution
> (where there is a choice or possibility that it can be done after
> execution starts, although I can still see problems where x, y, z refer
> to each other, but only one or two use constinit).
>
> And 'constexpr' treats them as readonly, but also allows such an
> expression to be considered a guaranteed compile-time expression, unlike
> static const, suitable for fixed arrays, switch cases, and for constant
> reduction.
>
> Yet, you also say constexpr expressions can have their address taken,
> and can use up storage, which is quite unlike a #define constant
> (earlier you had equated these two).
>
We can take the address of #define.
#define TEXT "text"
&TEXT
The point is not about the define is about the type of the object.
#define C 1
&C // error
The problem is that some types like integers we don't need/want storage. We don't want
a feature that creates storage for "free" without a good reason or by mistake.
(I cannot see any reason to create a storage for a integers). So enumerators are perfect in
this respect. )
constant of type double could repeat the same behavior of define not allowing address of.
The constant is a "named constant" and behaves the same of literal
const char* text = "text";
but here:
&text //address of constant of literal?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-30 17:49 +0200 |
| Message-ID | <telbi6$1gnds$1@dont-email.me> |
| In reply to | #167332 |
On 30/08/2022 15:58, Bart wrote:
> On 30/08/2022 12:15, David Brown wrote:
>> On 30/08/2022 02:51, bart c wrote:
>
>> (Being C++, this is really off-topic for c.l.c., but it might be of
>> interest to people here.)
>>
>>
>> In C++, you can write at file scope :
>>
>> int fib(int a) {
>> if (a < 2) return 1;
>> return fib(a - 1) + fib(a - 2);
>> }
>>
>>
>> int x = fib(5);
>> int y = fib(40);
>>
>>
>> The compiler may choose, as an optimisation, to pre-compute "fib(5)"
>> and use constant initialisation equivalent to "int x = 8;", so that
>> the memory for the variable "x" gets loaded with the value 8 before
>> main() or any other "real" code of the program runs. (You are
>> familiar with this initialisation procedure from C.)
>>
>> But for y, and optionally for x, the compiler will use run-time
>> initialisation. In effect, it generates "int y;" and a code section
>> that executes "y = fib(40);" and is run pre-main.
>>
>> Sometimes you don't want the possibility of having such run-time
>> initialisation, with all its potential complications such as startup
>> time, initialisation order, protection against race conditions for
>> function-local statics called from multiple threads, etc. But given
>> the code above, you cannot easily tell which, if either, of the
>> variable initialisations is done with a simple constant copy.
>>
>> To solve this, you first have to add "constexpr" to the "fib"
>> function. That tells the compiler that if it is given a constant
>> expression argument, the function can be evaluated at compile time to
>> give a constant expression result (while also still being usable at
>> runtime - "consteval" is the alternative to say that the function is
>> compile-time only and can never be used at runtime). This places
>> certain restrictions on the function - it has to be "pure", at least
>> for the particular constant values that you use in the program, but
>> that's fine here.
>>
>> Next, you label the variables as "constinit". This tells the compiler
>> that these functions must be initialised as constants, or compilation
>> will fail :
>>
>> constexpr int fib(int a) {
>> if (a < 2) return 1;
>> return fib(a - 1) + fib(a - 2);
>> }
>>
>> constinit int x = fib(5);
>> constinit int y = fib(40);
>>
>>
>> Now the compiler has no choice but to treat this as "int x = 8;" and
>> "int y = 165580141;". If the compiler can't do the calculation at
>> compile time (such as if I'd written fib(46), which at 2971215073
>> overflows a 32-bit int, or fib(41) which exceeds gcc's standard limit
>> of the number of steps it allows in a compile-time execution), then
>> the compiler halts with an error.
>>
>>
>> So "constinit" gives you tighter control of such initialisation. Note
>> that the variables "x" and "y" are still variables - it is only the
>> initialisation that is done by a constant, they are not constants
>> themselves (as they would be with "constexpr int x = fib(5);".
>> Indeed, the line "constinit int x = fib(5);" is equivalent to :
>>
>> constexpr int x_init = fib(5);
>> int x = x_init;
>
> OK, thanks.
>
> So 'constinit' means something should be evaluated before execution
> (where there is a choice or possibility that it can be done after
> execution starts, although I can still see problems where x, y, z refer
> to each other, but only one or two use constinit).
"constinit" means "initialise using a constant value that is known at
compile time". "constinit" variables are /not/ constants - it is their
initialisers that are constants. So it does not make sense for the
initialisation of one "constinit" variable to depend on the value of
another "constinit" variable. (They can depend on "constexpr" data, of
course, since those /are/ constant.)
>
> And 'constexpr' treats them as readonly, but also allows such an
> expression to be considered a guaranteed compile-time expression,
Yes. (Note that it does not imply that the object has to actually exist
in the memory image - the compiler can use the constant value directly.)
> unlike
> static const, suitable for fixed arrays, switch cases, and for constant
> reduction.
In C++, "static const" (or just plain "const", as these have static
linkage by default in C++, unlike in C) objects /can/ be used for some
things such as the size of fixed arrays.
And all sorts of things can be used for constant reduction by the
compiler - if the compiler knows there is no legal way for something to
change value, then the value can be used for optimisation regardless of
language rules about constants.
>
> Yet, you also say constexpr expressions can have their address taken,
> and can use up storage, which is quite unlike a #define constant
> (earlier you had equated these two).
I didn't equate the two - I said that for many uses of #define'd
constants, a constexpr object will do just as well and give identical
code (but with easier control of types, scoping of identifier, etc.).
Just because you /can/ take the address of a particular kind of object,
does not mean it is allocated to memory somewhere - the compiler will
only give it storage if its address /is/ taken, or if that is the most
efficient way to implement the actual use of the object. This is just
like local variables in a function - they don't get allocated slots on
the stack unless they have to, because you use their address or because
the compiler runs out of processor registers.
>
> So with between const, constinit, constexpr (plus enum and #define),
> with all their subtle differences, it is still not that clear, and there
> still isn't ONE feature that is a named constant, pure and simple.
>
You are picking your criteria for what /you/ call a "named constant"
very subjectively. There is no objective requirement for a language to
have a single concept that has all these features - it is better to have
different concepts that have different choices. For example, sometimes
it is useful for an identifier to ignore scope rules - then macros are
your choice.
> I'm not allowed to mention my stuff, but I'm referring to one that works
> like 'enum', but specifically intended for arbitrary named scalar values
> of a dominated type.
>
> Now that I've briefly reinstated a proper newsreader, I can show my
> earlier table in full; the columns show Yes when the desired attribute
> is True:
>
> #define enum const constexpr
>
> Uses normal scope rules No Yes Yes Yes
Yes.
> Won't create VLAs Yes Yes No? ?
In C, using a "const" object for the size of an array makes a VLA. In
C++, there are no VLAs - but you can use a const object for the size of
an array without it being a VLA. The generated code and the use of the
arrays will typically be identical. (constexpr array sizes are allowed
and do not lead to VLAs in either language.)
> Can't take their address Yes Yes No No?
True, but irrelevant. (I can't comprehend why you keep bringing this up.)
> Cannot modify Yes Yes Yes Yes?
True. (No need for question marks.)
> Can be used in switch cases Yes Yes No Yes?
"const int" can be used as a switch case in C++, but not in C.
> Can be reduced in expressions Yes Yes ?? Yes?
Yes for all (assuming the const is initialised in the same unit, and not
imported from another one).
> Can have any scalar type Yes? No Yes Yes
Yes.
> Can be used for static data init Yes Yes No Yes?
In C++, a const /can/ be used for static data initialisation, but only
if its own initialisation is static. (That's why you have "constinit"
to force this behaviour.)
> Not dependent on compiler Yes Yes No Yes?
I don't know what you mean here - compilers can do all kinds of
different things with each of these kinds of objects in different
circumstances. The language standards describe the observable
behaviour, not the implementation details.
> Uses storage No No Yes? Yes?
That makes no sense either. Unless you force the compiler's hand by
taking the address of an object (and even that is sometimes not enough),
objects may or may not be put in memory, depending on the most efficient
code generation. That applies equally to all of these.
> Value not context dependent No Yes Yes Yes
>
> (Last entry is new; for #define X = A+B, the value of X depends on the
> local values of A, B, whatever they are; it is not determined once at
> the point of definition.
Macros are textual substitution.
>
> 'Use storage' is from the language's POV; target instruction sets may
> not support immediate operands for all types, and are forced to use
> memory, but this applies also to literals like 123.456.)
That's a meaningless distinction. They all use storage if storage is
needed, or not if storage is not needed.
>
> Notice the right-hand two columns either have lots of Nos, or lots of
> question marks. The ideal feature will have solid Yeses.
Then you should be happy to see "constexpr" in C.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-30 09:02 -0700 |
| Message-ID | <0feeb097-4973-458b-a67d-504126cac237n@googlegroups.com> |
| In reply to | #167338 |
On Tuesday, August 30, 2022 at 12:49:39 PM UTC-3, David Brown wrote:
> On 30/08/2022 15:58, Bart wrote:
> > On 30/08/2022 12:15, David Brown wrote:
> >> On 30/08/2022 02:51, bart c wrote:
> >
> >> (Being C++, this is really off-topic for c.l.c., but it might be of
> >> interest to people here.)
> >>
> >>
> >> In C++, you can write at file scope :
> >>
> >> int fib(int a) {
> >> if (a < 2) return 1;
> >> return fib(a - 1) + fib(a - 2);
> >> }
> >>
> >>
> >> int x = fib(5);
> >> int y = fib(40);
> >>
> >>
> >> The compiler may choose, as an optimisation, to pre-compute "fib(5)"
> >> and use constant initialisation equivalent to "int x = 8;", so that
> >> the memory for the variable "x" gets loaded with the value 8 before
> >> main() or any other "real" code of the program runs. (You are
> >> familiar with this initialisation procedure from C.)
> >>
> >> But for y, and optionally for x, the compiler will use run-time
> >> initialisation. In effect, it generates "int y;" and a code section
> >> that executes "y = fib(40);" and is run pre-main.
> >>
> >> Sometimes you don't want the possibility of having such run-time
> >> initialisation, with all its potential complications such as startup
> >> time, initialisation order, protection against race conditions for
> >> function-local statics called from multiple threads, etc. But given
> >> the code above, you cannot easily tell which, if either, of the
> >> variable initialisations is done with a simple constant copy.
> >>
> >> To solve this, you first have to add "constexpr" to the "fib"
> >> function. That tells the compiler that if it is given a constant
> >> expression argument, the function can be evaluated at compile time to
> >> give a constant expression result (while also still being usable at
> >> runtime - "consteval" is the alternative to say that the function is
> >> compile-time only and can never be used at runtime). This places
> >> certain restrictions on the function - it has to be "pure", at least
> >> for the particular constant values that you use in the program, but
> >> that's fine here.
> >>
> >> Next, you label the variables as "constinit". This tells the compiler
> >> that these functions must be initialised as constants, or compilation
> >> will fail :
> >>
> >> constexpr int fib(int a) {
> >> if (a < 2) return 1;
> >> return fib(a - 1) + fib(a - 2);
> >> }
> >>
> >> constinit int x = fib(5);
> >> constinit int y = fib(40);
> >>
> >>
> >> Now the compiler has no choice but to treat this as "int x = 8;" and
> >> "int y = 165580141;". If the compiler can't do the calculation at
> >> compile time (such as if I'd written fib(46), which at 2971215073
> >> overflows a 32-bit int, or fib(41) which exceeds gcc's standard limit
> >> of the number of steps it allows in a compile-time execution), then
> >> the compiler halts with an error.
> >>
> >>
> >> So "constinit" gives you tighter control of such initialisation. Note
> >> that the variables "x" and "y" are still variables - it is only the
> >> initialisation that is done by a constant, they are not constants
> >> themselves (as they would be with "constexpr int x = fib(5);".
> >> Indeed, the line "constinit int x = fib(5);" is equivalent to :
> >>
> >> constexpr int x_init = fib(5);
> >> int x = x_init;
> >
> > OK, thanks.
> >
> > So 'constinit' means something should be evaluated before execution
> > (where there is a choice or possibility that it can be done after
> > execution starts, although I can still see problems where x, y, z refer
> > to each other, but only one or two use constinit).
> "constinit" means "initialise using a constant value that is known at
> compile time". "constinit" variables are /not/ constants - it is their
> initialisers that are constants. So it does not make sense for the
> initialisation of one "constinit" variable to depend on the value of
> another "constinit" variable. (They can depend on "constexpr" data, of
> course, since those /are/ constant.)
> >
> > And 'constexpr' treats them as readonly, but also allows such an
> > expression to be considered a guaranteed compile-time expression,
> Yes. (Note that it does not imply that the object has to actually exist
> in the memory image - the compiler can use the constant value directly.)
> > unlike
> > static const, suitable for fixed arrays, switch cases, and for constant
> > reduction.
> In C++, "static const" (or just plain "const", as these have static
> linkage by default in C++, unlike in C) objects /can/ be used for some
> things such as the size of fixed arrays.
>
> And all sorts of things can be used for constant reduction by the
> compiler - if the compiler knows there is no legal way for something to
> change value, then the value can be used for optimisation regardless of
> language rules about constants.
There as several questions I would like to ask for standard committed.
When C imported const from C++, probably they had a reason for
not copy C++ 100%? Maybe it was to keep C compilers simple?
But if this was the reason .. it was not applied to constexpr? ( I am not sure
it C23 constexpr will not use storage , maybe this is open to the implementation)
I think what basically what I would like to understand is why not improve const and NULL.
What are the big problems? The problem of creating a competing feature I already can see..
this is not new and C++ is following this path.
It is important to notice that C++ has other motivation for the same features.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-30 18:36 +0200 |
| Message-ID | <teleaj$1h1f4$1@dont-email.me> |
| In reply to | #167340 |
On 30/08/2022 18:02, Thiago Adams wrote:
> On Tuesday, August 30, 2022 at 12:49:39 PM UTC-3, David Brown wrote:
>> On 30/08/2022 15:58, Bart wrote:
>>> On 30/08/2022 12:15, David Brown wrote:
>>>> On 30/08/2022 02:51, bart c wrote:
>>>
>>>> (Being C++, this is really off-topic for c.l.c., but it might be of
>>>> interest to people here.)
>>>>
>>>>
>>>> In C++, you can write at file scope :
>>>>
>>>> int fib(int a) {
>>>> if (a < 2) return 1;
>>>> return fib(a - 1) + fib(a - 2);
>>>> }
>>>>
>>>>
>>>> int x = fib(5);
>>>> int y = fib(40);
>>>>
>>>>
>>>> The compiler may choose, as an optimisation, to pre-compute "fib(5)"
>>>> and use constant initialisation equivalent to "int x = 8;", so that
>>>> the memory for the variable "x" gets loaded with the value 8 before
>>>> main() or any other "real" code of the program runs. (You are
>>>> familiar with this initialisation procedure from C.)
>>>>
>>>> But for y, and optionally for x, the compiler will use run-time
>>>> initialisation. In effect, it generates "int y;" and a code section
>>>> that executes "y = fib(40);" and is run pre-main.
>>>>
>>>> Sometimes you don't want the possibility of having such run-time
>>>> initialisation, with all its potential complications such as startup
>>>> time, initialisation order, protection against race conditions for
>>>> function-local statics called from multiple threads, etc. But given
>>>> the code above, you cannot easily tell which, if either, of the
>>>> variable initialisations is done with a simple constant copy.
>>>>
>>>> To solve this, you first have to add "constexpr" to the "fib"
>>>> function. That tells the compiler that if it is given a constant
>>>> expression argument, the function can be evaluated at compile time to
>>>> give a constant expression result (while also still being usable at
>>>> runtime - "consteval" is the alternative to say that the function is
>>>> compile-time only and can never be used at runtime). This places
>>>> certain restrictions on the function - it has to be "pure", at least
>>>> for the particular constant values that you use in the program, but
>>>> that's fine here.
>>>>
>>>> Next, you label the variables as "constinit". This tells the compiler
>>>> that these functions must be initialised as constants, or compilation
>>>> will fail :
>>>>
>>>> constexpr int fib(int a) {
>>>> if (a < 2) return 1;
>>>> return fib(a - 1) + fib(a - 2);
>>>> }
>>>>
>>>> constinit int x = fib(5);
>>>> constinit int y = fib(40);
>>>>
>>>>
>>>> Now the compiler has no choice but to treat this as "int x = 8;" and
>>>> "int y = 165580141;". If the compiler can't do the calculation at
>>>> compile time (such as if I'd written fib(46), which at 2971215073
>>>> overflows a 32-bit int, or fib(41) which exceeds gcc's standard limit
>>>> of the number of steps it allows in a compile-time execution), then
>>>> the compiler halts with an error.
>>>>
>>>>
>>>> So "constinit" gives you tighter control of such initialisation. Note
>>>> that the variables "x" and "y" are still variables - it is only the
>>>> initialisation that is done by a constant, they are not constants
>>>> themselves (as they would be with "constexpr int x = fib(5);".
>>>> Indeed, the line "constinit int x = fib(5);" is equivalent to :
>>>>
>>>> constexpr int x_init = fib(5);
>>>> int x = x_init;
>>>
>>> OK, thanks.
>>>
>>> So 'constinit' means something should be evaluated before execution
>>> (where there is a choice or possibility that it can be done after
>>> execution starts, although I can still see problems where x, y, z refer
>>> to each other, but only one or two use constinit).
>> "constinit" means "initialise using a constant value that is known at
>> compile time". "constinit" variables are /not/ constants - it is their
>> initialisers that are constants. So it does not make sense for the
>> initialisation of one "constinit" variable to depend on the value of
>> another "constinit" variable. (They can depend on "constexpr" data, of
>> course, since those /are/ constant.)
>>>
>>> And 'constexpr' treats them as readonly, but also allows such an
>>> expression to be considered a guaranteed compile-time expression,
>> Yes. (Note that it does not imply that the object has to actually exist
>> in the memory image - the compiler can use the constant value directly.)
>>> unlike
>>> static const, suitable for fixed arrays, switch cases, and for constant
>>> reduction.
>> In C++, "static const" (or just plain "const", as these have static
>> linkage by default in C++, unlike in C) objects /can/ be used for some
>> things such as the size of fixed arrays.
>>
>> And all sorts of things can be used for constant reduction by the
>> compiler - if the compiler knows there is no legal way for something to
>> change value, then the value can be used for optimisation regardless of
>> language rules about constants.
>
> There as several questions I would like to ask for standard committed.
> When C imported const from C++, probably they had a reason for
> not copy C++ 100%? Maybe it was to keep C compilers simple?
> But if this was the reason .. it was not applied to constexpr? ( I am not sure
> it C23 constexpr will not use storage , maybe this is open to the implementation)
It is just like "static const". Whether you have "constexpr int x =
123;" or "static const int x = 123;", the code must act as though it had
put the object in storage. Each such object has a unique address, which
you can get with "&x".
In practice, however, no serious compiler would generate storage for
either "static const" or "constexpr" objects unless the storage is
actually needed. This is a "quality of implementation" issue - and
programmers (some, at least) rely on it for efficient results.
So I would expect /exactly/ the same object code and stored objects from:
int foo(void) { return 123; }
and
constexpr int a = 100;
static const int b = 20;
int foo(void) { return a + b + 3; }
>
> I think what basically what I would like to understand is why not improve const and NULL.
> What are the big problems? The problem of creating a competing feature I already can see..
> this is not new and C++ is following this path.
> It is important to notice that C++ has other motivation for the same features.
>
I agree that pretty much the same results could have been achieved with
changes and improvements to const and NULL. But by introducing these as
new features, there are three benefits. One is that there are no
changes to existing features - and therefore no risk of breakage of
code, nor of changing people's understanding of existing features. Two
is clarity of coding, which is improved for the programmer and also may
allow improved static error checking. And then there is compatibility
with C++ features - both from the viewpoint of code sharing (at least
headers), and from sharing knowledge and understanding for programmers.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-30 09:25 -0700 |
| Message-ID | <ceeb9966-789f-41dc-be20-13bebadfc5een@googlegroups.com> |
| In reply to | #167338 |
On Tuesday, August 30, 2022 at 12:49:39 PM UTC-3, David Brown wrote:
...
> > And 'constexpr' treats them as readonly, but also allows such an
> > expression to be considered a guaranteed compile-time expression,
> Yes. (Note that it does not imply that the object has to actually exist
> in the memory image - the compiler can use the constant value directly.)
> > unlike
> > static const, suitable for fixed arrays, switch cases, and for constant
> > reduction.
I posted this code in a C++ group on reddit asking where constexpr
is different from const in C++
This sample works in C++
#include <stdio.h>
template<int N>
struct A { int a[N];};
int main()
{
const int C = 1;
static_assert(C == 1);
int ar[C];
switch(C) {
case 1:break;
}
A<C> a;
}
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-30 05:31 -0700 |
| Message-ID | <84d0b63e-4a56-4107-b5b4-07f088bf0c8an@googlegroups.com> |
| In reply to | #167298 |
On Monday, August 29, 2022 at 11:47:18 AM UTC-3, David Brown wrote: > On 29/08/2022 13:59, Thiago Adams wrote: > > On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote: > > ... > >> Perhaps, however, C23's "constexpr" is actually closer to C++20's > >> "constinit" ? > > > > I did not know about C++20 constinit. It sounds like a joke for all the ways to > > define a constant in C++, but it's not a joke. > > > It's easy to mock things we don't understand. Just because /you/ don't > see the need of a feature in /your/ programming, does not mean it is not > useful to others. The problem is not if the feature is useful or not. The problem is a lot of concurrent almost identical features that are being piled to avoid changing the old ones. Unfortunately C followed this path for nullptr and constexpr. The is a good way to convince people to change/create another language. "Let's clean this mess"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-30 17:08 +0200 |
| Message-ID | <tel957$1gfqt$1@dont-email.me> |
| In reply to | #167330 |
On 30/08/2022 14:31, Thiago Adams wrote: > On Monday, August 29, 2022 at 11:47:18 AM UTC-3, David Brown wrote: >> On 29/08/2022 13:59, Thiago Adams wrote: >>> On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote: >>> ... >>>> Perhaps, however, C23's "constexpr" is actually closer to C++20's >>>> "constinit" ? >>> >>> I did not know about C++20 constinit. It sounds like a joke for all the ways to >>> define a constant in C++, but it's not a joke. >>> >> It's easy to mock things we don't understand. Just because /you/ don't >> see the need of a feature in /your/ programming, does not mean it is not >> useful to others. > > The problem is not if the feature is useful or not. The problem is a lot of > concurrent almost identical features that are being piled to avoid changing > the old ones. Unfortunately C followed this path for nullptr and constexpr. > > The is a good way to convince people to change/create another language. > "Let's clean this mess" > There are three things you can do with a language: 1. Avoid any new features, and let it stagnate. 2. Make significant changes that improve the language, at the cost of breaking compatibility with existing code. 3. Make additions to the language to allow better code to be written, but keep older features even if they are superseded by the new ones. C and C++ both aim for option 3, though C is far more careful about breakage and C++ is more willing to be experimental and mover forward. You are advocating for option 2 - throw out the old, outdated, or replaced features when there are new and better ways to handle things. That's okay for a new language in heavy development, but it has been shown again and again to be a big problem with established languages. About the only serious mainstream language that has successfully followed that strategy is Python, and even there the breaking changes between major versions are kept to a minimum. If you want a language with the features of C++ (or C) that you like, and without the cruft inherited over the decades, then create a new language from scratch. Neither C nor C++ drop more than a very small number of features because programmers need to use existing code more than they need to use newer standards.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-30 08:40 -0700 |
| Message-ID | <196dfb13-b1e1-400b-b737-b83fb25024e1n@googlegroups.com> |
| In reply to | #167336 |
On Tuesday, August 30, 2022 at 12:08:36 PM UTC-3, David Brown wrote: > On 30/08/2022 14:31, Thiago Adams wrote: > > On Monday, August 29, 2022 at 11:47:18 AM UTC-3, David Brown wrote: > >> On 29/08/2022 13:59, Thiago Adams wrote: > >>> On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote: > >>> ... > >>>> Perhaps, however, C23's "constexpr" is actually closer to C++20's > >>>> "constinit" ? > >>> > >>> I did not know about C++20 constinit. It sounds like a joke for all the ways to > >>> define a constant in C++, but it's not a joke. > >>> > >> It's easy to mock things we don't understand. Just because /you/ don't > >> see the need of a feature in /your/ programming, does not mean it is not > >> useful to others. > > > > The problem is not if the feature is useful or not. The problem is a lot of > > concurrent almost identical features that are being piled to avoid changing > > the old ones. Unfortunately C followed this path for nullptr and constexpr. > > > > The is a good way to convince people to change/create another language. > > "Let's clean this mess" > > > There are three things you can do with a language: > > 1. Avoid any new features, and let it stagnate. > > 2. Make significant changes that improve the language, at the cost of > breaking compatibility with existing code. > > 3. Make additions to the language to allow better code to be written, > but keep older features even if they are superseded by the new ones. > > > C and C++ both aim for option 3, though C is far more careful about > breakage and C++ is more willing to be experimental and mover forward. > > You are advocating for option 2 - throw out the old, outdated, or > replaced features when there are new and better ways to handle things. There are more and better options: 4 - Adding features that complements instead of competing with existent features C++ 17 "if with initialiser" was not added into c23. I would add it and I believe it belong to this category. other samples _has_include was added elifdef was added #warning was added 5 - Changing current behaviour without negative impact. static_assert with 1 argument. No negative impact. Today 1.0 == 1.0 is not a constant expression. It could be without negative impact. The same for "a"[0] old style declarations were removed.. I think there is no negative impact. > If you want a language with the features of C++ (or C) that you like, > and without the cruft inherited over the decades, then create a new > language from scratch. Neither C nor C++ drop more than a very small > number of features because programmers need to use existing code more > than they need to use newer standards. I think it is possible to improve C keeping it almost compatible with old versions. The worst case is adding features that compete with previous ones not adding enough value to justify the price to be paid. like nullptr and constexpr.
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web