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 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-31 17:48 +0100 |
| Message-ID | <87bks0pdex.fsf@bsb.me.uk> |
| In reply to | #167379 |
David Brown <david.brown@hesbynett.no> writes: > However, this was in response to Bart's particular request, not > programmers in general - he asked for a named constant that would be > "exactly the same as though [he]'d written" the value directly in the > source code. That's what C pre-processor macros do. Yes, I saw that, but I can't help wanting a more productive debate by interpreting what people write rather than being too literal about it. Bartc did not mean "just like a macro" even if what he wrote could be taken that way. >> Bartc wants to drag everyone into his "isn't C awful" narrative, but >> (rightly) avoiding such pointless moaning can be done without suggesting >> that macros are like named (r)values. > > I was not suggesting that at all - I was pointing out that his > specific requirements are covered by macros. OK. I assumed you had grasped what Bartc wants from a named constant and were suggesting that macros provided that, but you were just taking his words as literally as possible. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 19:58 +0200 |
| Message-ID | <teo7fi$1sepn$1@dont-email.me> |
| In reply to | #167386 |
On 31/08/2022 18:48, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> However, this was in response to Bart's particular request, not >> programmers in general - he asked for a named constant that would be >> "exactly the same as though [he]'d written" the value directly in the >> source code. That's what C pre-processor macros do. > > Yes, I saw that, but I can't help wanting a more productive debate by > interpreting what people write rather than being too literal about it. > Bartc did not mean "just like a macro" even if what he wrote could be > taken that way. > That's a fair point - though trying to figure out what someone meant to write, rather than what they actually wrote, has challenges of its own! >>> Bartc wants to drag everyone into his "isn't C awful" narrative, but >>> (rightly) avoiding such pointless moaning can be done without suggesting >>> that macros are like named (r)values. >> >> I was not suggesting that at all - I was pointing out that his >> specific requirements are covered by macros. > > OK. I assumed you had grasped what Bartc wants from a named constant > and were suggesting that macros provided that, but you were just taking > his words as literally as possible. > I believe I have a reasonable idea of what he wants, but I am not convinced he is consistent - he has a long history of changing what he wants for a given feature if he finds out that C or C++ support what he asked for. Speaking for myself, what I want from a "named constant value" can vary somewhat according to the circumstances - and I don't think I am alone in sometimes using "const", sometimes "static const", sometimes "enum", sometimes "#define" and - in the future - sometimes "constexpr". Sometimes textual substitution /is/ what a programmer wants - and since Bart asked for that explicitly, I wanted to see why he did not like macros for that particular task. I still can't understand why he wants it to be impossible to take the address of a named constant, however. (I understand, and I agree with, wanting the compiler to reject - or at least warn about by default - clear attempts at overwriting data declared as constant.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 20:31 +0100 |
| Message-ID | <teoctp$rmr$1@gioia.aioe.org> |
| In reply to | #167395 |
On 31/08/2022 18:58, David Brown wrote: > On 31/08/2022 18:48, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> However, this was in response to Bart's particular request, not >>> programmers in general - he asked for a named constant that would be >>> "exactly the same as though [he]'d written" the value directly in the >>> source code. That's what C pre-processor macros do. >> >> Yes, I saw that, but I can't help wanting a more productive debate by >> interpreting what people write rather than being too literal about it. >> Bartc did not mean "just like a macro" even if what he wrote could be >> taken that way. >> > > That's a fair point - though trying to figure out what someone meant to > write, rather than what they actually wrote, has challenges of its own! > >>>> Bartc wants to drag everyone into his "isn't C awful" narrative, but >>>> (rightly) avoiding such pointless moaning can be done without >>>> suggesting >>>> that macros are like named (r)values. >>> >>> I was not suggesting that at all - I was pointing out that his >>> specific requirements are covered by macros. >> >> OK. I assumed you had grasped what Bartc wants from a named constant >> and were suggesting that macros provided that, but you were just taking >> his words as literally as possible. >> > > I believe I have a reasonable idea of what he wants, but I am not > convinced he is consistent - he has a long history of changing what he > wants for a given feature if he finds out that C or C++ support what he > asked for. > > Speaking for myself, what I want from a "named constant value" can vary > somewhat according to the circumstances - and I don't think I am alone > in sometimes using "const", sometimes "static const", sometimes "enum", > sometimes "#define" and - in the future - sometimes "constexpr". > Sometimes textual substitution /is/ what a programmer wants - and since > Bart asked for that explicitly, I wanted to see why he did not like > macros for that particular task. > > I still can't understand why he wants it to be impossible to take the > address of a named constant, however. 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?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-31 13:01 -0700 |
| Message-ID | <871qswi3nc.fsf@nosuchdomain.example.com> |
| In reply to | #167399 |
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.
(And if I didn't have to worry about backward compatibility, "const"
would be spelled "readonly", and variables would be read-only by
default with a "var" keyword if you want to able to modify them.
I don't propose making that kind of change in any language called
"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 15:26 -0700 |
| Message-ID | <d5bb14b9-9421-4ca6-bcdb-f869579089d8n@googlegroups.com> |
| In reply to | #167402 |
On Wednesday, August 31, 2022 at 5:01:29 PM UTC-3, Keith Thompson wrote:
> Bart <b...@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 don't think this is a problem
this code works in C++.
constexpr int a[] = {1, 2, 3};
static_assert(a[0] == 1);
I believe, internally this is evaluated by an interpreter. No need for the address.
this also compiles.. that is more interesting.
constexpr int a[] = {1, 2, 3};
static_assert(*(&a[0]) == 1);
> 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.
Very similar what I think.. I would like a different constexpr but
even with a different version I don't think its worthwhile.
I think it is valid as a experiment see what happens adding a
full language interpreter inside the compiler..but I would never suggest
for C23.
This evaluator could be used in optimisation.. no need especial constexpr keyword.
for instance
int f(int i) { return i * 2};
int i = f(2); //compiler changes to 4 nothing change in the language
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-31 15:42 -0700 |
| Message-ID | <87wnaoghlj.fsf@nosuchdomain.example.com> |
| In reply to | #167404 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Wednesday, August 31, 2022 at 5:01:29 PM UTC-3, Keith Thompson wrote:
>> Bart <b...@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 don't think this is a problem
>
> this code works in C++.
>
> constexpr int a[] = {1, 2, 3};
> static_assert(a[0] == 1);
>
> I believe, internally this is evaluated by an interpreter. No need for the address.
Sure, but the definition of the indexing operator requires an address,
even if that address can be optimized away. If I write:
std::cout << a[0];
I'd expect generated code equivalent to
std::cout << 1;
but logically the expression `a[0]` is still equivalent to `*(a+0)`.
The problem is not implementing the evaluation (though that's certainly
not trivial), it's defining it semantically. `a` has an address, and in
fact you can evaluate `&a`. If `a` didn't have an address, you'd need
wording in the standard to define what `a[0]` means in that case.
(Or maybe the C++ standard already does this. I haven't checked.)
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-01 10:00 +0200 |
| Message-ID | <tepoqu$24ah6$1@dont-email.me> |
| In reply to | #167405 |
On 01/09/2022 00:42, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On Wednesday, August 31, 2022 at 5:01:29 PM UTC-3, Keith Thompson wrote:
>>> Bart <b...@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 don't think this is a problem
>>
>> this code works in C++.
>>
>> constexpr int a[] = {1, 2, 3};
>> static_assert(a[0] == 1);
>>
>> I believe, internally this is evaluated by an interpreter. No need for the address.
>
> Sure, but the definition of the indexing operator requires an address,
> even if that address can be optimized away. If I write:
> std::cout << a[0];
> I'd expect generated code equivalent to
> std::cout << 1;
> but logically the expression `a[0]` is still equivalent to `*(a+0)`.
>
> The problem is not implementing the evaluation (though that's certainly
> not trivial), it's defining it semantically. `a` has an address, and in
> fact you can evaluate `&a`. If `a` didn't have an address, you'd need
> wording in the standard to define what `a[0]` means in that case.
>
> (Or maybe the C++ standard already does this. I haven't checked.)
>
> [...]
>
AFAIUI, the constexpr qualified data has storage and lifetimes exactly
like non-constexpr qualified data, as far as the standards are
concerned. It is up to the implementation to handle it efficiently
(usually not storing it anywhere - but if necessary, choosing either
read-only sections or code sections according to standards for the
target processor).
C and C++ compilers always generated code according to the "as if" rule.
So the static_assert above acts "as if" the array were in memory, and
the value at address "a + 0" were read. The "constexpr" qualifier gives
the compiler the right to assume the contents of that memory, so that it
can be "read" at compile-time.
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.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-09-01 04:35 -0700 |
| Message-ID | <943104c2-d6d5-40db-9fb5-61c1417f77d4n@googlegroups.com> |
| In reply to | #167410 |
On Thursday, September 1, 2022 at 5:00:47 AM UTC-3, David Brown wrote:
> On 01/09/2022 00:42, Keith Thompson wrote:
> > Thiago Adams <thiago...@gmail.com> writes:
> >> On Wednesday, August 31, 2022 at 5:01:29 PM UTC-3, Keith Thompson wrote:
> >>> Bart <b...@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 don't think this is a problem
> >>
> >> this code works in C++.
> >>
> >> constexpr int a[] = {1, 2, 3};
> >> static_assert(a[0] == 1);
> >>
> >> I believe, internally this is evaluated by an interpreter. No need for the address.
> >
> > Sure, but the definition of the indexing operator requires an address,
> > even if that address can be optimized away. If I write:
> > std::cout << a[0];
> > I'd expect generated code equivalent to
> > std::cout << 1;
> > but logically the expression `a[0]` is still equivalent to `*(a+0)`.
> >
> > The problem is not implementing the evaluation (though that's certainly
> > not trivial), it's defining it semantically. `a` has an address, and in
> > fact you can evaluate `&a`. If `a` didn't have an address, you'd need
> > wording in the standard to define what `a[0]` means in that case.
> >
> > (Or maybe the C++ standard already does this. I haven't checked.)
> >
> > [...]
> >
> AFAIUI, the constexpr qualified data has storage and lifetimes exactly
> like non-constexpr qualified data, as far as the standards are
> concerned. It is up to the implementation to handle it efficiently
> (usually not storing it anywhere - but if necessary, choosing either
> read-only sections or code sections according to standards for the
> target processor).
>
> C and C++ compilers always generated code according to the "as if" rule.
> So the static_assert above acts "as if" the array were in memory, and
> the value at address "a + 0" were read. The "constexpr" qualifier gives
> the compiler the right to assume the contents of that memory, so that it
> can be "read" at compile-time.
>
> 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.
The situation where is necessary the "address of constant",
is already covered by the language:
For instance let's say we have:
struct Options { int flag1; };
We can use:
header:
extern const struct Options defaultOptions;
source:
const struct Options defaultOptions = { .flag1 = 1 };
.. and pass this object to a function that doesn't care
if it is a constant or not.
Like:
void Process(const struct Options* options){...}
It doesn't make sense to pass a pointer to PI or for gravitational
constant for instance.
So making a struct Options available for "compile time"
is much more related with a C++ world of constexpr functions.
It doesn't make sense in C. Still don't believed this was added
int C23 so fast.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-01 15:10 -0700 |
| Message-ID | <87sflahhkp.fsf@nosuchdomain.example.com> |
| In reply to | #167410 |
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. 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).
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).
--
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-02 00:09 +0100 |
| Message-ID | <tere45$1448$1@gioia.aioe.org> |
| In reply to | #167421 |
On 01/09/2022 23: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. 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).
>
> 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).
You're starting to come over to the point of view of myself and Thiago
Adams, but you're not quite convinced that compilers ought to be more
responsible.
The solution to this const/constexpr issue is obvious; you've stated it
above: use a safer, purpose-made feature that doesn't have those dangers.
Let me pose this question of anybody: gcc for example puts certain
constant values into readonly memory.
Why does it do that? Since according to most here, that should never be
necessary for anyone who understands the language inside out, knows all
the UBs, gives all the correct options, does all the right testing.
Perhaps it does so just in case. Well, perhaps it might be an idea to
use your 'constant' feature just in case too! Preventing a bug at
compile-time is better than trapping it at runtime.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-02 09:30 +0200 |
| Message-ID | <tesbel$2fn49$1@dont-email.me> |
| In reply to | #167421 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-02 13:24 +0100 |
| Message-ID | <tessl6$19la$1@gioia.aioe.org> |
| In reply to | #167423 |
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.
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.
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-09-02 05:56 -0700 |
| Message-ID | <fb2376f7-b105-4146-8c93-dcca3a7ebabdn@googlegroups.com> |
| In reply to | #167424 |
On Friday, September 2, 2022 at 9:24:23 AM UTC-3, Bart wrote:
> On 02/09/2022 08:30, David Brown wrote:
> > On 02/09/2022 00:10, Keith Thompson wrote:
> >> David Brown <david...@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.
>
> 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.
How about compound literals?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-02 15:14 +0100 |
| Message-ID | <tet337$amb$1@gioia.aioe.org> |
| In reply to | #167425 |
On 02/09/2022 13:56, Thiago Adams wrote:
> On Friday, September 2, 2022 at 9:24:23 AM UTC-3, Bart wrote:
>> On 02/09/2022 08:30, David Brown wrote:
>>> On 02/09/2022 00:10, Keith Thompson wrote:
>>>> David Brown <david...@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.
>>
>> 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.
>
> How about compound literals?
The 'literal' in those is just a term somebody decided use. (Elsewhere I
would call them constructors.)
But even if they are considered literals, then so what? I've showed in a
another post how string literals (which also can be of arbitrary length,
known to use storage, and usually manipulated via a pointer), can be
still be named literals with many of the attributes that are expected.
The only thing that can't be guaranteed is being impossible to modify,
since they do use storage and have an accessible address.
This then crosses the line between named values and named objects.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-02 16:19 +0100 |
| Message-ID | <87fsh9iz25.fsf@bsb.me.uk> |
| In reply to | #167427 |
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. > (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". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-02 17:52 +0100 |
| Message-ID | <tetcd0$o2q$1@gioia.aioe.org> |
| In reply to | #167430 |
On 02/09/2022 16:19, Ben Bacarisse wrote:
> 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.
>
>> (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.
But when you can get a constructor like this (which C likes to enclose
in braces instead):
(a, b, c, d)
Now, the elements of such a construct may be compile-time constants, or
they might not be. They might also be themselves be constructors, making
them very different from those designators for numbers and strings.
Those I wouldn't call literals.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-09-02 10:01 -0700 |
| Message-ID | <11d1020d-144d-4da0-88c1-3d56b4160c2an@googlegroups.com> |
| In reply to | #167431 |
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.
For instance:
((int []){1, 2, 3})
or
((struct X { int i ; } ){.i = 2})
(
by the way, in C23 compound literal can have storage
specifier, static constexpr..
Like
((static int []){1, 2, 3})
)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-02 11:50 -0700 |
| Message-ID | <87bkrxhap9.fsf@nosuchdomain.example.com> |
| In reply to | #167432 |
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.
Not necessarily. A compound literal at block scope can contain
non-constant expressions.
struct foo { int a; int b; };
struct foo obj;
obj = (struct foo) { .a = rand(), .b = rand() };
> For instance:
> ((int []){1, 2, 3})
> or
> ((struct X { int i ; } ){.i = 2})
>
> (
> by the way, in C23 compound literal can have storage
> specifier, static constexpr..
> Like
> ((static int []){1, 2, 3})
> )
That's handy. It means that you can write a compound literal at block
scope whose associated object doesn't vanish at the end of the block.
With `static`, you can return a pointer to it. It gives you behavior
more similar to string literals.
--
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-09-02 12:18 -0700 |
| Message-ID | <0b7017d5-4b82-4638-92a2-0ee064cca65en@googlegroups.com> |
| In reply to | #167437 |
On Friday, September 2, 2022 at 3:51:16 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@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.
> Not necessarily. A compound literal at block scope can contain
> non-constant expressions.
Yes..what I was trying to say is that they can be constant as well.
> struct foo { int a; int b; };
> struct foo obj;
> obj = (struct foo) { .a = rand(), .b = rand() };
> > For instance:
> > ((int []){1, 2, 3})
> > or
> > ((struct X { int i ; } ){.i = 2})
> >
> > (
> > by the way, in C23 compound literal can have storage
> > specifier, static constexpr..
> > Like
> > ((static int []){1, 2, 3})
> > )
> That's handy. It means that you can write a compound literal at block
> scope whose associated object doesn't vanish at the end of the block.
> With `static`, you can return a pointer to it. It gives you behavior
> more similar to string literals.
Yes. I liked this extra control.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-02 20:45 +0100 |
| Message-ID | <87pmgdh85z.fsf@bsb.me.uk> |
| In reply to | #167432 |
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. Bart had a point here. The only guaranteed compile-time literal part is the structure and not the actual value. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web