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 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-13 15:52 -0700 |
| Message-ID | <86fsguopk6.fsf@linuxsc.com> |
| In reply to | #167639 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > scott@slp53.sl.home (Scott Lurndal) writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > > <cut> > >>> constexpr unsigned int all_ones = -1; >> >> Wouldn't it be more natural to write >> >> constexpr unsigned int all_ones = ~1; > > You surely meant ~0, yes? > >> I'd never use your suggestion in real code; I've seen programmers do >> it, but it has never been proper. > > I have exactly the opposite reaction. The conversion of -1 to an > unsigned integer type is very explicitly described in such a way that > the maximum number of value bits must be set. This contrasts with ~0 > that might even be a trap representation. > > (~0u on the other had is well-defined.) Using either ~0u or -1u has the drawback that the intended target type is specified redundantly. These expressions might do the wrong thing if the variable being declared, as one example, were of type unsigned long rather than unsigned int. Using plain -1 doesn't have that drawback: it works for a variable declaration having _any_ unsigned type.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-13 17:24 -0700 |
| Message-ID | <86bkriolao.fsf@linuxsc.com> |
| In reply to | #167638 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Thiago Adams <thiago.adams@gmail.com> writes: >>> >>>> An interesting exercise is to think about true and false as >>>> constexpr. Imagine we have bool in the language but we don't >>>> have true and false constants. >>>> >>>> Then we declare: >>>> >>>> constexpr bool true = 1; >>>> constexpr bool false = 0; >>> >>> In this hypothetical situation, presumably 1 and 0 are the actual >>> values that bool objects represent. If not, this would be a >>> constraint violation as the standard is deliberately strict about >>> constexpr initialisers: they undergo no conversions. >>> >>> It's not 100% clear to me if, in the finished C23, >>> >>> constexpr bool my_bool = 1; >>> >>> will be permitted. I think not. >> >> I agree with (what I think is) your conclusion that the latest C23 >> draft standard (n3047) deems the initializing expression of >> my_bool a constraint violation. >> >> However, I do not think that n3047 disallows all conversions (that >> are implicit; AFAICS casting is always allowed). My understanding >> is that implicit conversions are allowed provided they do not >> cause a change of abstract value. For example, a definition such >> as >> >> constexpr unsigned int unsigned_one = 1; >> >> would be allowed, because the conversion from int to unsigned int >> does not change the abstract value 1. But the definition of >> my_bool above is not allowed, because the implicit conversion from >> int to bool changes the abstract value 1 to the abstract value >> true. Similarly a definition such as >> >> constexpr unsigned int all_ones = -1; > > Wouldn't it be more natural to write > > constexpr unsigned int all_ones = ~1; One, using ~0 as the initializing expression has the same constraint violation as -1 does. Two, it may be more common for beginners to write ~0u, but hopefully that is something they outgrow as they gain experience with C's rules for conversions, and other experience. There are various expressions that might be used: ~0u, -1u, ~(unsigned)0, 0u-1, etc. All of these choices have the same problem: they are brittle by virtue of giving a redundant specification of type. Change the type of the declaration and the initializing expression can have a wrong value. By contrast using -1 works whether the variable being declared is an unsigned char, unsigned short, unsigned int, unsigned long, unsigned long long, uint47_t, uint_least29_t, size_t, uintmax_t, or any other unsigned type. Code that is less brittle is better. > I'd never use your suggestion in real code; I've seen programmers > do it, but it has never been proper. It has always been proper. Apparently what is lacking is some programmers' understanding of C's conversion rules and an appreciation for writing code that always works rather than writing code that is brittle.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-28 22:55 +0200 |
| Message-ID | <tegko6$oaad$1@dont-email.me> |
| In reply to | #167262 |
On 28/08/2022 21:49, Thiago Adams wrote: > On Sunday, August 28, 2022 at 4:31:48 PM UTC-3, Thiago Adams wrote: >> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: >>> On 28/08/2022 15:11, Thiago Adams wrote: >>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: >>> >>>>> However, I would expect "constexpr" to be a relatively uncontroversial >>>>> feature once people start to use it. >>>> >>>> >>>> There are a lot of details about storage of constexpr. >>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf >>>> >>>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static >>>> has automatic storage duration, the identifier has no linkage, and each instance of the object >>>> has a unique address obtainable with & (if it is not declared with the register specifier), if any. >>>> Such an object in file scope has static storage duration, the corresponding identifier >>>> has internal linkage, and each translation unit that sees the same textual definition implements >>>> a separate object with a distinct address." >>>> >>> Do you see anything there you don't like, or which is not pretty obvious? >> I don't like constexpr mainly because it has storage and it is too similar of const. >> But even without storage I would not recommend constexpr without >> a extensive analysis to give more power to const. The same for nullptr, give more >> power to NULL. > > An interesting exercise is to think about true and false as constexpr. > Imagine we have bool in the language but we don't have true and false > constants. > > Then we declare: > > constexpr bool true = 1; > constexpr bool false = 0; Let's rather write : constexpr bool True = true; constexpr bool False = false; since that does not conflict with either pre-C23 or post-C23 booleans. > > bool b = true; bool b = True; > > The "real" true /false constants don't have storage and we cannot take the address of. > The same for nullptr. > I am at a loss to understand why you think this is so important. If you don't want to take the address of "True", then don't write "&True". The compiler will generate identical code for "bool b = true;" and "bool b = True;", whether at file scope or local scope. Are you under the impression that writing "constexpr bool True = true;" would /force/ the compiler to generate an addressable object in memory, and that "bool b = True;" would force it to generate code that read that object?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-28 22:51 +0200 |
| Message-ID | <tegkgb$o8cj$1@dont-email.me> |
| In reply to | #167260 |
On 28/08/2022 21:31, Thiago Adams wrote:
> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote:
>> On 28/08/2022 15:11, Thiago Adams wrote:
>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote:
>>
>>>> However, I would expect "constexpr" to be a relatively uncontroversial
>>>> feature once people start to use it.
>>>
>>>
>>> There are a lot of details about storage of constexpr.
>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf
>>>
>>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static
>>> has automatic storage duration, the identifier has no linkage, and each instance of the object
>>> has a unique address obtainable with & (if it is not declared with the register specifier), if any.
>>> Such an object in file scope has static storage duration, the corresponding identifier
>>> has internal linkage, and each translation unit that sees the same textual definition implements
>>> a separate object with a distinct address."
>>>
>> Do you see anything there you don't like, or which is not pretty obvious?
>
> I don't like constexpr mainly because it has storage and it is too similar of const.
Storage is up to the compiler. If the code can be compiled without any
storage for the object, then no storage is needed. But you /can/ take
the address of a constexpr object if you want. That would be very
useful if you have, say, a function that takes a const pointer to a
struct - you can pass it a constexpr struct if you like.
I think it would have been a little better to say that it is unspecified
whether different instances of the same constexpr object have the same
address or unique addresses. But it is likely that very few constexpr
objects have any address or storage in practice.
> But even without storage I would not recommend constexpr without
> a extensive analysis to give more power to const. The same for nullptr, give more
> power to NULL.
>
> const in C++ already behave like a constant expression.
>
> IN C++
>
> int main() {
> const int c = 10;
> int a[c];
> static_assert(sizeof a == sizeof(int)*10);
> }
>
> (In c a is a VLA)
>
> So it is not new that we can have different behaviour with const
> compiling the same code in C or C++.
>
I too would have liked to have had more "powerful" const in C. But I do
like the distinction. In C++, objects with static (program) lifetime
can have non-constant initialisers and be initialised by run-time code.
This can be surprising, is inefficient and messy for multiple threads,
and there is the infamous issue of order of initialisation. C does not
have that because all static lifetime objects are initialised with
constants (either an explicit constant, or implicit zero) before main()
starts. constexpr lets you continue this distinction, keeping it
absolutely clear to both programmer and compiler, while allowing more
complicated initialisers.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 14:57 -0700 |
| Message-ID | <90aaf37e-e48d-40c4-ad98-bf34533af2ben@googlegroups.com> |
| In reply to | #167264 |
On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote: > On 28/08/2022 21:31, Thiago Adams wrote: > > On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: > >> On 28/08/2022 15:11, Thiago Adams wrote: > >>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: > >> > >>>> However, I would expect "constexpr" to be a relatively uncontroversial > >>>> feature once people start to use it. > >>> > >>> > >>> There are a lot of details about storage of constexpr. > >>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf > >>> > >>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static > >>> has automatic storage duration, the identifier has no linkage, and each instance of the object > >>> has a unique address obtainable with & (if it is not declared with the register specifier), if any. > >>> Such an object in file scope has static storage duration, the corresponding identifier > >>> has internal linkage, and each translation unit that sees the same textual definition implements > >>> a separate object with a distinct address." > >>> > >> Do you see anything there you don't like, or which is not pretty obvious? > > > > I don't like constexpr mainly because it has storage and it is too similar of const. > Storage is up to the compiler. If the code can be compiled without any > storage for the object, then no storage is needed. But you /can/ take > the address of a constexpr object if you want. That would be very > useful if you have, say, a function that takes a const pointer to a > struct - you can pass it a constexpr struct if you like. I am very uncomfortable with "may" or "may not" have storage specially in headers. In C++, const is like that even before constexpr. I think other programmer are uncomfortable with that as well because I don't remember to see c++ libs defining constants (using const) in header files. It is a big mess. We need a big comparison table C++ const x C const C++ const x C++ constexp ... In C23 if "constexpr" power was added to "const" one difference is that arrays size with "const" would transform from VLA to static arrays. Is that bad? And in C11 const always have storage (I think) and adding this extra power const it would become more similar of c++ const. "It may not have storage" I think more consideration was necessary before adding this feature but at the end "copy c++ with" was the motivation for constexpr and nullptr. Also the initial motivation for nullptr in C++ was different from the initial motivation for nullptr in C. In c++ NULL was 0 because ((void*)0) in C++ would generate warnings of converting void* to something else. With C++ overload it was ambiguous F(NULL) calling F(int i) or F(void *). Again the motivation in C23 seems to be "let's see what we can copy from C++" Nothing wrong with that..I liked static_assert , _has_include.. etc..but C needs to be more careful in my view. And I thought C was careful until the "last round" where nullptr and contexpr where added.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-29 00:46 +0200 |
| Message-ID | <tegr7n$pf6h$1@dont-email.me> |
| In reply to | #167267 |
On 28/08/2022 23:57, Thiago Adams wrote: > On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote: >> On 28/08/2022 21:31, Thiago Adams wrote: >>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: >>>> On 28/08/2022 15:11, Thiago Adams wrote: >>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: >>>> >>>>>> However, I would expect "constexpr" to be a relatively uncontroversial >>>>>> feature once people start to use it. >>>>> >>>>> >>>>> There are a lot of details about storage of constexpr. >>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf >>>>> >>>>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static >>>>> has automatic storage duration, the identifier has no linkage, and each instance of the object >>>>> has a unique address obtainable with & (if it is not declared with the register specifier), if any. >>>>> Such an object in file scope has static storage duration, the corresponding identifier >>>>> has internal linkage, and each translation unit that sees the same textual definition implements >>>>> a separate object with a distinct address." >>>>> >>>> Do you see anything there you don't like, or which is not pretty obvious? >>> >>> I don't like constexpr mainly because it has storage and it is too similar of const. >> Storage is up to the compiler. If the code can be compiled without any >> storage for the object, then no storage is needed. But you /can/ take >> the address of a constexpr object if you want. That would be very >> useful if you have, say, a function that takes a const pointer to a >> struct - you can pass it a constexpr struct if you like. > > I am very uncomfortable with "may" or "may not" have storage specially in headers. > Do you have trouble with "static const" data? They are /exactly/ like constexpr data in this respect. > In C++, const is like that even before constexpr. > > I think other programmer are uncomfortable with that as well because > I don't remember to see c++ libs defining constants (using const) in header files. > C++ headers do it all the time. If you want a constant value in a header, and it does not naturally form part of an enumeration, in C++ you just have "const int number = 123;" in the header (in effect, it is like "static const" in C). In more modern C++, you'd probably make it "constexpr", but many don't bother with that (often it makes no significant difference). > > It is a big mess. We need a big comparison table > > C++ const x C const They are much the same, except that in C++ a file-scope (or namespace-scope) const is "static" by default, while it is external linkage by default in C. The rules of how you can initialise them are a bit different - C++ is more flexible. > C++ const x C++ constexp "constexpr" initialisers have to be known at compile time, and you can use them for things that need such compile-time knowledge (such as in templates and static assertions). But that makes the initialisers more restrictive. > ... > > In C23 if "constexpr" power was added to "const" one difference is > that arrays size with "const" would transform from VLA to static arrays. > Is that bad? No, it would not be bad. > > And in C11 const always have storage (I think) No. Const with external linkage have storage, unless it is then dropped by a smart linker. Static const generally only have storage if the compiler sees they need storage. > and adding this extra power const > it would become more similar of c++ const. "It may not have storage" > C++ const is identical to C const in this respect, though the default linkage is different. > I think more consideration was necessary before adding this feature > but at the end "copy c++ with" was the motivation for constexpr and nullptr. > I suspect that the folks that spent the time thinking through the feature, writing the proposals, reviewing and updating the proposals, voting on them, and updating the standards to include them /have/ considered them. I suspect they have considered them a great deal more than either you or I. > Also the initial motivation for nullptr in C++ was different from the initial > motivation for nullptr in C. In c++ NULL was 0 because ((void*)0) in C++ > would generate warnings of converting void* to something else. > With C++ overload it was ambiguous F(NULL) calling F(int i) or F(void *). > > Again the motivation in C23 seems to be "let's see what we can copy from C++" > Nothing wrong with that..I liked static_assert , _has_include.. etc..but > C needs to be more careful in my view. And I thought C was careful until the "last round" > where nullptr and contexpr where added. I doubt if nullptr would have been added to C23 if it did not exist in C++. But I think it is fine to import useful, popular features from C++ that are without conflict (baring negligible identifier conflict risks) with existing C code or the "C philosophy", and which have no cost or bother for people who don't want to use the feature.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 16:13 -0700 |
| Message-ID | <1da3bd6e-e373-407c-af1d-5fb63285484fn@googlegroups.com> |
| In reply to | #167268 |
On Sunday, August 28, 2022 at 7:46:29 PM UTC-3, David Brown wrote: > On 28/08/2022 23:57, Thiago Adams wrote: > > On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote: > >> On 28/08/2022 21:31, Thiago Adams wrote: > >>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: > >>>> On 28/08/2022 15:11, Thiago Adams wrote: > >>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: > >>>> > >>>>>> However, I would expect "constexpr" to be a relatively uncontroversial > >>>>>> feature once people start to use it. > >>>>> > >>>>> > >>>>> There are a lot of details about storage of constexpr. > >>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf > >>>>> > >>>>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static > >>>>> has automatic storage duration, the identifier has no linkage, and each instance of the object > >>>>> has a unique address obtainable with & (if it is not declared with the register specifier), if any. > >>>>> Such an object in file scope has static storage duration, the corresponding identifier > >>>>> has internal linkage, and each translation unit that sees the same textual definition implements > >>>>> a separate object with a distinct address." > >>>>> > >>>> Do you see anything there you don't like, or which is not pretty obvious? > >>> > >>> I don't like constexpr mainly because it has storage and it is too similar of const. > >> Storage is up to the compiler. If the code can be compiled without any > >> storage for the object, then no storage is needed. But you /can/ take > >> the address of a constexpr object if you want. That would be very > >> useful if you have, say, a function that takes a const pointer to a > >> struct - you can pass it a constexpr struct if you like. > > > > I am very uncomfortable with "may" or "may not" have storage specially in headers. > > > Do you have trouble with "static const" data? They are /exactly/ like > constexpr data in this respect. It is very uncommon in my code. > > In C++, const is like that even before constexpr. > > > > I think other programmer are uncomfortable with that as well because > > I don't remember to see c++ libs defining constants (using const) in header files. > > > C++ headers do it all the time. If you want a constant value in a > header, and it does not naturally form part of an enumeration, in C++ > you just have "const int number = 123;" in the header (in effect, it is > like "static const" in C). In more modern C++, you'd probably make it > "constexpr", but many don't bother with that (often it makes no > significant difference). > > > > It is a big mess. We need a big comparison table > > > > C++ const x C const > They are much the same, except that in C++ a file-scope (or > namespace-scope) const is "static" by default, while it is external > linkage by default in C. The rules of how you can initialise them are a > bit different - C++ is more flexible. > > C++ const x C++ constexp > "constexpr" initialisers have to be known at compile time, and you can > use them for things that need such compile-time knowledge (such as in > templates and static assertions). But that makes the initialisers more > restrictive. > > ... > > > > In C23 if "constexpr" power was added to "const" one difference is > > that arrays size with "const" would transform from VLA to static arrays. > > Is that bad? > No, it would not be bad. > > > > And in C11 const always have storage (I think) > No. Const with external linkage have storage, unless it is then dropped > by a smart linker. Static const generally only have storage if the > compiler sees they need storage. > > and adding this extra power const > > it would become more similar of c++ const. "It may not have storage" > > > C++ const is identical to C const in this respect, though the default > linkage is different. > > I think more consideration was necessary before adding this feature > > but at the end "copy c++ with" was the motivation for constexpr and nullptr. > > > I suspect that the folks that spent the time thinking through the > feature, writing the proposals, reviewing and updating the proposals, > voting on them, and updating the standards to include them /have/ > considered them. I suspect they have considered them a great deal more > than either you or I. > > Also the initial motivation for nullptr in C++ was different from the initial > > motivation for nullptr in C. In c++ NULL was 0 because ((void*)0) in C++ > > would generate warnings of converting void* to something else. > > With C++ overload it was ambiguous F(NULL) calling F(int i) or F(void *). > > > > Again the motivation in C23 seems to be "let's see what we can copy from C++" > > Nothing wrong with that..I liked static_assert , _has_include.. etc..but > > C needs to be more careful in my view. And I thought C was careful until the "last round" > > where nullptr and contexpr where added. > I doubt if nullptr would have been added to C23 if it did not exist in > C++. But I think it is fine to import useful, popular features from C++ > that are without conflict (baring negligible identifier conflict risks) > with existing C code or the "C philosophy", and which have no cost or > bother for people who don't want to use the feature. I don't want to be rude with the work and effort of many people trying to improve C. But I think some features needs to be more maturated even if no problem is found. (Like a quarantine) I guess they know about this as well. C++ has features added and then removed. At the time the feature was approved everyone was happy. C is not a language that competes in features with other languages. I guess C programmers are the most happy programmers because of that. So there is no rush. I think the justification for constexpr/nullptr is that is is not new because it is already used by C++. But I it is important to note that a lot of people are complaining about C++ complexity so I am not sure we can say the feature is a success because it used already used by C++. These concurrent features (mess?) may be the reason people moved from C++ to other languages and the reason new language are created.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-29 08:47 +0200 |
| Message-ID | <tehndq$vlce$1@dont-email.me> |
| In reply to | #167269 |
On 29/08/2022 01:13, Thiago Adams wrote: > On Sunday, August 28, 2022 at 7:46:29 PM UTC-3, David Brown wrote: >> On 28/08/2022 23:57, Thiago Adams wrote: >>> On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote: >>>> On 28/08/2022 21:31, Thiago Adams wrote: >>>>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: >>>>>> On 28/08/2022 15:11, Thiago Adams wrote: >>>>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: >>>>>> >>>>>>>> However, I would expect "constexpr" to be a relatively uncontroversial >>>>>>>> feature once people start to use it. >>>>>>> >>>>>>> >>>>>>> There are a lot of details about storage of constexpr. >>>>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf >>>>>>> >>>>>>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static >>>>>>> has automatic storage duration, the identifier has no linkage, and each instance of the object >>>>>>> has a unique address obtainable with & (if it is not declared with the register specifier), if any. >>>>>>> Such an object in file scope has static storage duration, the corresponding identifier >>>>>>> has internal linkage, and each translation unit that sees the same textual definition implements >>>>>>> a separate object with a distinct address." >>>>>>> >>>>>> Do you see anything there you don't like, or which is not pretty obvious? >>>>> >>>>> I don't like constexpr mainly because it has storage and it is too similar of const. >>>> Storage is up to the compiler. If the code can be compiled without any >>>> storage for the object, then no storage is needed. But you /can/ take >>>> the address of a constexpr object if you want. That would be very >>>> useful if you have, say, a function that takes a const pointer to a >>>> struct - you can pass it a constexpr struct if you like. >>> >>> I am very uncomfortable with "may" or "may not" have storage specially in headers. >>> >> Do you have trouble with "static const" data? They are /exactly/ like >> constexpr data in this respect. > > It is very uncommon in my code. They are common in mine. Most, of course, are in the C files rather than headers - any data used by a particular module that does not need to be changed will be "const", and anything that is not exported will be "static". But they also turn up regularly in headers - I much prefer "static const int last_index = 123;" to "#define last_index 123". In C23, I expect to prefer "constexpr int last_index = 123;", once the standard is well-supported in compilers. >>> >>> Again the motivation in C23 seems to be "let's see what we can copy from C++" >>> Nothing wrong with that..I liked static_assert , _has_include.. etc..but >>> C needs to be more careful in my view. And I thought C was careful until the "last round" >>> where nullptr and contexpr where added. >> I doubt if nullptr would have been added to C23 if it did not exist in >> C++. But I think it is fine to import useful, popular features from C++ >> that are without conflict (baring negligible identifier conflict risks) >> with existing C code or the "C philosophy", and which have no cost or >> bother for people who don't want to use the feature. > > I don't want to be rude with the work and effort of many people trying to > improve C. But I think some features needs to be more maturated > even if no problem is found. (Like a quarantine) I guess they know about > this as well. > > C++ has features added and then removed. At the time the feature was > approved everyone was happy. > This is an advantage of copying features from C++ to C - these features /are/ mature, and well tested. They have been implemented, widely used, and their pros and cons understood. You are absolutely right that C should not be as "experimental" as C++, and they are not. Few features are added to C that are not already in heavy use either in standard C++, or in extensions to C implemented in real-world compilers. > C is not a language that competes in features with other languages. I guess C > programmers are the most happy programmers because of that. > > So there is no rush. No one is rushing here - this is C23 we are talking about, gaining features that have been popular in C++ for a decade. > I think the justification for constexpr/nullptr is that is is not new > because it is already used by C++. But I it is important to note that a lot of people are > complaining about C++ complexity so I am not sure we can say the feature is > a success because it used already used by C++. These concurrent features (mess?) > may be the reason people moved from C++ to other languages and the reason > new language are created. > C is not picking up exceptions, co-routines, or move semantics, or templated lambdas! These are simple features - easy to understand, easy to use, entirely optional for programmers, and fitting fine with C.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 20:13 -0700 |
| Message-ID | <efdc6093-e297-410d-aaad-585b7d4f72ban@googlegroups.com> |
| In reply to | #167268 |
On Sunday, August 28, 2022 at 7:46:29 PM UTC-3, David Brown wrote:
> On 28/08/2022 23:57, Thiago Adams wrote:
> > On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote:
> >> On 28/08/2022 21:31, Thiago Adams wrote:
> >>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote:
> >>>> On 28/08/2022 15:11, Thiago Adams wrote:
> >>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote:
> >>>>
> >>>>>> However, I would expect "constexpr" to be a relatively uncontroversial
> >>>>>> feature once people start to use it.
> >>>>>
> >>>>>
> >>>>> There are a lot of details about storage of constexpr.
> >>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf
> >>>>>
> >>>>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static
> >>>>> has automatic storage duration, the identifier has no linkage, and each instance of the object
> >>>>> has a unique address obtainable with & (if it is not declared with the register specifier), if any.
> >>>>> Such an object in file scope has static storage duration, the corresponding identifier
> >>>>> has internal linkage, and each translation unit that sees the same textual definition implements
> >>>>> a separate object with a distinct address."
> >>>>>
> >>>> Do you see anything there you don't like, or which is not pretty obvious?
> >>>
> >>> I don't like constexpr mainly because it has storage and it is too similar of const.
> >> Storage is up to the compiler. If the code can be compiled without any
> >> storage for the object, then no storage is needed. But you /can/ take
> >> the address of a constexpr object if you want. That would be very
> >> useful if you have, say, a function that takes a const pointer to a
> >> struct - you can pass it a constexpr struct if you like.
> >
> > I am very uncomfortable with "may" or "may not" have storage specially in headers.
> >
> Do you have trouble with "static const" data? They are /exactly/ like
> constexpr data in this respect.
I did some tests in C++
Any of these ways will produce the same assembler ouput.
const double PI = 3.14;
constexpr double PI = 3.14;
static const double PI = 3.14;
#define PI 3.14
int square(int num) {
return num * PI;
}
changing double to int then it is different. The integer constant is not
placed at the data segment unless you take the address &.
I want to know if C23 implementations will implement like C const that is
always at data segment or if they will be on data segment only if you take the address.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-28 20:30 -0700 |
| Message-ID | <b5f228e0-7110-44ec-8d1d-3c79e5b600ben@googlegroups.com> |
| In reply to | #167276 |
On Monday, August 29, 2022 at 12:13:19 AM UTC-3, Thiago Adams wrote:.. > I want to know if C23 implementations will implement like C const that is > always at data segment or if they will be on data segment only if you take the address. If constexpr in c23 is implemented to "detected address of" then the same could be done for const making it equivalent of c++.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-29 09:36 +0200 |
| Message-ID | <tehq9d$vtdu$1@dont-email.me> |
| In reply to | #167276 |
On 29/08/2022 05:13, Thiago Adams wrote:
> On Sunday, August 28, 2022 at 7:46:29 PM UTC-3, David Brown wrote:
>> On 28/08/2022 23:57, Thiago Adams wrote:
>>> On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote:
>>>> On 28/08/2022 21:31, Thiago Adams wrote:
>>>>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote:
>>>>>> On 28/08/2022 15:11, Thiago Adams wrote:
>>>>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote:
>>>>>>
>>>>>>>> However, I would expect "constexpr" to be a relatively uncontroversial
>>>>>>>> feature once people start to use it.
>>>>>>>
>>>>>>>
>>>>>>> There are a lot of details about storage of constexpr.
>>>>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf
>>>>>>>
>>>>>>> "NOTE An object declared in block scope with a storage-class specifier constexpr and without static
>>>>>>> has automatic storage duration, the identifier has no linkage, and each instance of the object
>>>>>>> has a unique address obtainable with & (if it is not declared with the register specifier), if any.
>>>>>>> Such an object in file scope has static storage duration, the corresponding identifier
>>>>>>> has internal linkage, and each translation unit that sees the same textual definition implements
>>>>>>> a separate object with a distinct address."
>>>>>>>
>>>>>> Do you see anything there you don't like, or which is not pretty obvious?
>>>>>
>>>>> I don't like constexpr mainly because it has storage and it is too similar of const.
>>>> Storage is up to the compiler. If the code can be compiled without any
>>>> storage for the object, then no storage is needed. But you /can/ take
>>>> the address of a constexpr object if you want. That would be very
>>>> useful if you have, say, a function that takes a const pointer to a
>>>> struct - you can pass it a constexpr struct if you like.
>>>
>>> I am very uncomfortable with "may" or "may not" have storage specially in headers.
>>>
>> Do you have trouble with "static const" data? They are /exactly/ like
>> constexpr data in this respect.
>
> I did some tests in C++
> Any of these ways will produce the same assembler ouput.
>
> const double PI = 3.14;
> constexpr double PI = 3.14;
> static const double PI = 3.14;
> #define PI 3.14
>
> int square(int num) {
> return num * PI;
> }
>
> changing double to int then it is different. The integer constant is not
> placed at the data segment unless you take the address &.
>
> I want to know if C23 implementations will implement like C const that is
> always at data segment or if they will be on data segment only if you take the address.
I thought you worked on compilers? How do you not understand how this
works?
Compilers generate assembly code that gives the observable behaviour as
the source code requires. No storage of any kind need be generated
unless it is required for the observable behaviour. Equally, storage
can be generated regardless of what the standards may say about it (such
as lifetimes or linkage) if it is required for the generated code to
work correctly.
So if the target processor here has assembly instructions of the form
"load register with immediate value 3.14", it can generate that for each
of your C++ constant types. Most processors do not, so they generate
the instruction "load register with value at address XXX", and place the
value 3.14 in memory with address label XXX. That memory might be a
"read-only data" segment, part of the "text/code" segment, or somewhere
else, depending on the target.
Most processors /do/ have a "load register with immediate value 314"
instruction, and thus don't have to put the 314 integer in memory anywhere.
The choice of putting the value in memory is about code generation for
the target, not the way the constant is defined in the code. And it
will never (in any compiler I have seen) be in the "data" section - if
memory is needed, it will be in the "code" section, "read-only data"
section, "const" section, or similar.
The exception is if you have a "const" object with external linkage
(i.e., not "static const" in C, or with an explicit "extern const" in
C++). Then there must also be an externally visible constant in memory,
available to other translation units at link time. The defining unit
may still use "load immediate" instructions if they are more efficient -
it is not required to read the data from the memory. (And it can also
pre-calculate expressions using the constant, or other optimisations
based in the value, since it knows the const object can never change
value.) It is not uncommon for smarter linkers (especially with
link-time optimisation) to drop these objects from memory if they are
not needed at link-time.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 00:43 +0100 |
| Message-ID | <tem7ak$1dgg$1@gioia.aioe.org> |
| In reply to | #167268 |
On 28/08/2022 23:46, David Brown wrote:
> On 28/08/2022 23:57, Thiago Adams wrote:
>> On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote:
>>> On 28/08/2022 21:31, Thiago Adams wrote:
>>>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote:
>>>>> On 28/08/2022 15:11, Thiago Adams wrote:
>>>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote:
>>>>>
>>>>>>> However, I would expect "constexpr" to be a relatively
>>>>>>> uncontroversial
>>>>>>> feature once people start to use it.
>>>>>>
>>>>>>
>>>>>> There are a lot of details about storage of constexpr.
>>>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf
>>>>>>
>>>>>> "NOTE An object declared in block scope with a storage-class
>>>>>> specifier constexpr and without static
>>>>>> has automatic storage duration, the identifier has no linkage, and
>>>>>> each instance of the object
>>>>>> has a unique address obtainable with & (if it is not declared with
>>>>>> the register specifier), if any.
>>>>>> Such an object in file scope has static storage duration, the
>>>>>> corresponding identifier
>>>>>> has internal linkage, and each translation unit that sees the same
>>>>>> textual definition implements
>>>>>> a separate object with a distinct address."
>>>>>>
>>>>> Do you see anything there you don't like, or which is not pretty
>>>>> obvious?
>>>>
>>>> I don't like constexpr mainly because it has storage and it is too
>>>> similar of const.
>>> Storage is up to the compiler. If the code can be compiled without any
>>> storage for the object, then no storage is needed. But you /can/ take
>>> the address of a constexpr object if you want. That would be very
>>> useful if you have, say, a function that takes a const pointer to a
>>> struct - you can pass it a constexpr struct if you like.
>>
>> I am very uncomfortable with "may" or "may not" have storage specially
>> in headers.
>>
>
> Do you have trouble with "static const" data? They are /exactly/ like
> constexpr data in this respect.
>
>> In C++, const is like that even before constexpr.
>>
>> I think other programmer are uncomfortable with that as well because
>> I don't remember to see c++ libs defining constants (using const) in
>> header files.
>>
>
> C++ headers do it all the time. If you want a constant value in a
> header, and it does not naturally form part of an enumeration, in C++
> you just have "const int number = 123;" in the header (in effect, it is
> like "static const" in C). In more modern C++, you'd probably make it
> "constexpr", but many don't bother with that (often it makes no
> significant difference).
So, 'const int abc' doesn't automatically export 'abc' in a C++ header?
Or, presumably, from a C++ module? What do you do when you /do/ want to
export it?
Does it actually take storage, and if so how does it take care of things
when the same header containing 'const int abc=123' is included by 50
modules? Suppose some of those take its address, will it be to the same
object, or N distinct ones?
This is what I don't like about both languages. 'abc' may or may not be
exported; it may or may not be shared; it may or may not allow
address-of; it may or may not count as a compile-time value.
There is no ONE feature to create a named constant which has no storage
accessible to the program; can't have its address taken; has only one
instance; and can be either confidently kept local or confidently exported.
Your comments point to this behaviour:
const int abc; // C: always exports
const int abc; // C++: never exports
static const int abc; // C: never exports
This does not inspire confidence!
(I know you hate me mentioning my stuff but I solved this long, long
ago. Every time I need to write C, I need to learn again how to juggle
static, extern, const, define, enum to achieve what I can so simply do
elsewhere.)
As I suggested before, the introduction of 'constexpr' is not going to
make things better, just even more of a mess.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 10:44 +0200 |
| Message-ID | <ten727$1otnm$1@dont-email.me> |
| In reply to | #167352 |
On 31/08/2022 01:43, Bart wrote: > On 28/08/2022 23:46, David Brown wrote: >> On 28/08/2022 23:57, Thiago Adams wrote: >>> On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote: >>>> On 28/08/2022 21:31, Thiago Adams wrote: >>>>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: >>>>>> On 28/08/2022 15:11, Thiago Adams wrote: >>>>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: >>>>>> >>>>>>>> However, I would expect "constexpr" to be a relatively >>>>>>>> uncontroversial >>>>>>>> feature once people start to use it. >>>>>>> >>>>>>> >>>>>>> There are a lot of details about storage of constexpr. >>>>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf >>>>>>> >>>>>>> "NOTE An object declared in block scope with a storage-class >>>>>>> specifier constexpr and without static >>>>>>> has automatic storage duration, the identifier has no linkage, >>>>>>> and each instance of the object >>>>>>> has a unique address obtainable with & (if it is not declared >>>>>>> with the register specifier), if any. >>>>>>> Such an object in file scope has static storage duration, the >>>>>>> corresponding identifier >>>>>>> has internal linkage, and each translation unit that sees the >>>>>>> same textual definition implements >>>>>>> a separate object with a distinct address." >>>>>>> >>>>>> Do you see anything there you don't like, or which is not pretty >>>>>> obvious? >>>>> >>>>> I don't like constexpr mainly because it has storage and it is too >>>>> similar of const. >>>> Storage is up to the compiler. If the code can be compiled without any >>>> storage for the object, then no storage is needed. But you /can/ take >>>> the address of a constexpr object if you want. That would be very >>>> useful if you have, say, a function that takes a const pointer to a >>>> struct - you can pass it a constexpr struct if you like. >>> >>> I am very uncomfortable with "may" or "may not" have storage >>> specially in headers. >>> >> >> Do you have trouble with "static const" data? They are /exactly/ like >> constexpr data in this respect. >> >>> In C++, const is like that even before constexpr. >>> >>> I think other programmer are uncomfortable with that as well because >>> I don't remember to see c++ libs defining constants (using const) in >>> header files. >>> >> >> C++ headers do it all the time. If you want a constant value in a >> header, and it does not naturally form part of an enumeration, in C++ >> you just have "const int number = 123;" in the header (in effect, it >> is like "static const" in C). In more modern C++, you'd probably make >> it "constexpr", but many don't bother with that (often it makes no >> significant difference). > > So, 'const int abc' doesn't automatically export 'abc' in a C++ header? > Or, presumably, from a C++ module? What do you do when you /do/ want to > export it? You add an "extern" to give it external linkage. File-scope (or namespace-scope, in C++) objects have either internal linkage or external linkage - they are either localised in scope to the current unit, or visible from any unit. "static" forces internal linkage, and "extern" forces external linkage. A major flaw in C, IMHO, is that the default is external linkage unless explicitly made internal linkage. C++ changed that default for "const" when that language was developed, but C retained the default for "const" data. > > Does it actually take storage, and if so how does it take care of things > when the same header containing 'const int abc=123' is included by 50 > modules? Suppose some of those take its address, will it be to the same > object, or N distinct ones? As I have said several times in different branches of this thread, /real/ compilers do not allocate storage for constants of any kind (or variables, for that matter) unless there is a need for it. So your 50 units that include "const int abc = 123;" all have, hypothetically, independent objects in memory with unique addresses. In practice you would not expect /any/ of these to exist in memory. (C++ also has a way to say that particular objects are merged even though they are initialised in multiple units, but that depends on linker features and comes as a necessity for template instantiation, and is not relevant to C.) > > This is what I don't like about both languages. 'abc' may or may not be > exported; it may or may not be shared; it may or may not allow > address-of; it may or may not count as a compile-time value. The rules are fairly clear (I've tried to explain them) - though unfortunately slightly different for C and C++ in regard to "const". The languages support different possibilities here because that's what people need - sometimes you want an object to be exported, sometimes not, and so on. > > There is no ONE feature to create a named constant which has no storage > accessible to the program; can't have its address taken; has only one > instance; and can be either confidently kept local or confidently exported. (Again - I do not understand your obsession about "can't have its address taken". Such a "feature" does not in any way imply that the object is not in memory or does not take storage space. Nor does support for address-of imply that the object /does/ take storage space. There are many cases in programming where "you are not allowed to do this" is a useful feature as it supports cleaner, clearer and safer programming. But this is not, IMHO, such a case.) > > Your comments point to this behaviour: > > const int abc; // C: always exports > const int abc; // C++: never exports > static const int abc; // C: never exports > > This does not inspire confidence! static const int abc = 123; // Always internal linkage extern const int def = 456; // Always external linkage const int x = 123; // "static" in C++, "extern" in C. If you need confidence, learn the rules - look for patterns and reasoning, rather than assuming everything is flawed. You are not stupid - stop pretending this is too complicated for you. > > (I know you hate me mentioning my stuff but I solved this long, long > ago. Every time I need to write C, I need to learn again how to juggle > static, extern, const, define, enum to achieve what I can so simply do > elsewhere.) > > As I suggested before, the introduction of 'constexpr' is not going to > make things better, just even more of a mess. For people who are willing to learn the languages they use or discuss, "constexpr" is a useful feature that adds to the language. For people who would rather focus on how they think things are complicated, or make excuses for their own misunderstandings, "constexpr" is yet another feature to complain about. It's fine if you don't like C, or don't want to use C, or prefer other languages, or find C hard to learn. But if you are not ready to learn the language or a feature of it, and to understand why it is in the language and what use people make of it, then you give up your right to express an informed opinion that people should take seriously. You are left with your right to an uninformed opinion that people will often ignore. (Or, for a while at least, people may try to inform you and correct you.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-31 04:50 -0700 |
| Message-ID | <b14c53b9-7577-43c5-871f-db827a25dc3cn@googlegroups.com> |
| In reply to | #167360 |
On Wednesday, August 31, 2022 at 5:45:10 AM UTC-3, David Brown wrote: > On 31/08/2022 01:43, Bart wrote: > > On 28/08/2022 23:46, David Brown wrote: > >> On 28/08/2022 23:57, Thiago Adams wrote: > >>> On Sunday, August 28, 2022 at 5:51:37 PM UTC-3, David Brown wrote: > >>>> On 28/08/2022 21:31, Thiago Adams wrote: > >>>>> On Sunday, August 28, 2022 at 12:20:35 PM UTC-3, David Brown wrote: > >>>>>> On 28/08/2022 15:11, Thiago Adams wrote: > >>>>>>> On Sunday, August 28, 2022 at 5:27:35 AM UTC-3, David Brown wrote: > >>>>>> > >>>>>>>> However, I would expect "constexpr" to be a relatively > >>>>>>>> uncontroversial > >>>>>>>> feature once people start to use it. > >>>>>>> > >>>>>>> > >>>>>>> There are a lot of details about storage of constexpr. > >>>>>>> https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf > >>>>>>> > >>>>>>> "NOTE An object declared in block scope with a storage-class > >>>>>>> specifier constexpr and without static > >>>>>>> has automatic storage duration, the identifier has no linkage, > >>>>>>> and each instance of the object > >>>>>>> has a unique address obtainable with & (if it is not declared > >>>>>>> with the register specifier), if any. > >>>>>>> Such an object in file scope has static storage duration, the > >>>>>>> corresponding identifier > >>>>>>> has internal linkage, and each translation unit that sees the > >>>>>>> same textual definition implements > >>>>>>> a separate object with a distinct address." > >>>>>>> > >>>>>> Do you see anything there you don't like, or which is not pretty > >>>>>> obvious? > >>>>> > >>>>> I don't like constexpr mainly because it has storage and it is too > >>>>> similar of const. > >>>> Storage is up to the compiler. If the code can be compiled without any > >>>> storage for the object, then no storage is needed. But you /can/ take > >>>> the address of a constexpr object if you want. That would be very > >>>> useful if you have, say, a function that takes a const pointer to a > >>>> struct - you can pass it a constexpr struct if you like. > >>> > >>> I am very uncomfortable with "may" or "may not" have storage > >>> specially in headers. > >>> > >> > >> Do you have trouble with "static const" data? They are /exactly/ like > >> constexpr data in this respect. > >> > >>> In C++, const is like that even before constexpr. > >>> > >>> I think other programmer are uncomfortable with that as well because > >>> I don't remember to see c++ libs defining constants (using const) in > >>> header files. > >>> > >> > >> C++ headers do it all the time. If you want a constant value in a > >> header, and it does not naturally form part of an enumeration, in C++ > >> you just have "const int number = 123;" in the header (in effect, it > >> is like "static const" in C). In more modern C++, you'd probably make > >> it "constexpr", but many don't bother with that (often it makes no > >> significant difference). I don't see people using "const int number = 123;" in C++ headers. Do you use const in in headers? I don't. (C or C++) I think more programmers have the same feeling of "I am creating a variable read-only" that may or may not be true.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-31 05:48 -0700 |
| Message-ID | <c6c620c1-91d5-46de-acb1-eba7c0cf8a29n@googlegroups.com> |
| In reply to | #167364 |
On Wednesday, August 31, 2022 at 8:50:16 AM UTC-3, Thiago Adams wrote:
...
> I don't see people using "const int number = 123;" in C++ headers.
> Do you use const in in headers? I don't. (C or C++)
>
> I think more programmers have the same feeling of
> "I am creating a variable read-only" that may or may not be true.
This code also compiles in C++.
const int C = 1;
int main() {
int i = C;
switch (i) {
case C: break;
}
}
I never wrote code like this.
One justification for unpopular use of const as "constant" in C++ may be
because its differences from C or maybe because sometimes it is
a read-only variable and sometimes it works as "constant".
constexpr also have this hybrid mode. the main difference
is that constexpr must be initialised with something know at
compile time.
This code shows constexpr used as variable
#include <stdio.h>
void F2(const int *p) {
printf("%d", *p);
}
void F(int j) {
constexpr int i = 1+2;
F2(&i);
}
This c++ code shows that "compile time" is a broad concept .
#include <stdio.h>
struct X { int i = 0; };
constexpr struct X x = X();
static_assert(X().i == 0, ""); //works at compile time
void F2(const struct X *px) {
}
void F(int j) {
F2(&x);
}
So in C++ the idea of "constant expression" or "compile time" is something
much broader than just numeric expressions.
I think C23 constexpr already expanded the concept of "constant expression"
in C. See 6.6 Constant expressions at 3077.pdf
So C compilers now will have a much bigger compile time evaluator
that need to deal with floating point and also with compound literals.
"Starting from a structure or union constant, the member-access . operator
may be used to form a named constant or compound literal constant
as described above."
For instance:
static_assert ( ((struct X { double i; } ){ .i = 1.2 + 1.3}).i == 1.2 + 1.3);
This will bring some extra complication for simple c compilers.
It hard to believe how such a feature was approved so fast.
For instance even before the idea of broader constant expression
was added.
Even this is illegal in C11.
_Static_assert(1.0 == 1.0, "");
All this compile time in C++ I think is a valid as experiment.
But for C programmers the feature that was missing is much simpler than
that and it was not introduced.
That is a simple "named constant" or I prefer a "named literal".(string literal, number, compound)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 14:31 +0100 |
| Message-ID | <tennsa$10bs$1@gioia.aioe.org> |
| In reply to | #167366 |
On 31/08/2022 13:48, Thiago Adams wrote:
> On Wednesday, August 31, 2022 at 8:50:16 AM UTC-3, Thiago Adams wrote:
> ...
>> I don't see people using "const int number = 123;" in C++ headers.
>> Do you use const in in headers? I don't. (C or C++)
>>
>> I think more programmers have the same feeling of
>> "I am creating a variable read-only" that may or may not be true.
>
> This code also compiles in C++.
>
> const int C = 1;
>
> int main() {
> int i = C;
> switch (i) {
> case C: break;
> }
> }
>
> I never wrote code like this.
>
> One justification for unpopular use of const as "constant" in C++ may be
> because its differences from C or maybe because sometimes it is
> a read-only variable and sometimes it works as "constant".
>
> constexpr also have this hybrid mode. the main difference
> is that constexpr must be initialised with something know at
> compile time.
>
> This code shows constexpr used as variable
>
> #include <stdio.h>
>
> void F2(const int *p) {
> printf("%d", *p);
> }
> void F(int j) {
> constexpr int i = 1+2;
> F2(&i);
> }
>
> This c++ code shows that "compile time" is a broad concept .
> #include <stdio.h>
>
> struct X { int i = 0; };
> constexpr struct X x = X();
>
> static_assert(X().i == 0, ""); //works at compile time
>
> void F2(const struct X *px) {
> }
>
> void F(int j) {
> F2(&x);
> }
>
> So in C++ the idea of "constant expression" or "compile time" is something
> much broader than just numeric expressions.
>
> I think C23 constexpr already expanded the concept of "constant expression"
> in C. See 6.6 Constant expressions at 3077.pdf
>
> So C compilers now will have a much bigger compile time evaluator
> that need to deal with floating point and also with compound literals.
>
> "Starting from a structure or union constant, the member-access . operator
> may be used to form a named constant or compound literal constant
> as described above."
>
> For instance:
> static_assert ( ((struct X { double i; } ){ .i = 1.2 + 1.3}).i == 1.2 + 1.3);
>
> This will bring some extra complication for simple c compilers.
>
> It hard to believe how such a feature was approved so fast.
> For instance even before the idea of broader constant expression
> was added.
>
> Even this is illegal in C11.
> _Static_assert(1.0 == 1.0, "");
>
>
> All this compile time in C++ I think is a valid as experiment.
> But for C programmers the feature that was missing is much simpler than
> that and it was not introduced.
> That is a simple "named constant" or I prefer a "named literal".(string literal, number, compound)
This is what I've been advocating here for years. But people seem to
prefer using a combination of #define, enum, const.
They especially seem keen on 'const', which is a read-only attribute for
variables.
I think if some had their way, they'd use 'const' exclusively for named
literals, but C doesn't allow their values for non-VLA array bounds, and
for switch-case.
So along comes 'constexpr', which is just like 'const', but now that
pesky restriction is done away with. (Plus it has all that extra
complexity you mentioned, for good measure.)
C, or C people, just do not like that extra indirection level (of type,
but can also be of access) that marks the difference between named
values and named variables.
The solution could be trivial; this is what I use outside of C (DB will
get very cross when he sees this):
const abc = 123 # 'const int' is optional (type-inferred)
let int def = 456 # read-only variable
int ghi = 789 # 'var int' is optional
'const' is not C's const, it is just a named constant, I believe just
the feature you'd prefer.
The above is at file scope where def/ghi are static, and their
initialisation values must be compile-time expressions.
Inside a function, def/ghi would need initialising with ':=', which does
a runtime assignment.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-31 15:15 +0100 |
| Message-ID | <871qswsdn2.fsf@bsb.me.uk> |
| In reply to | #167371 |
Bart <bc@freeuk.com> writes: > On 31/08/2022 13:48, Thiago Adams wrote: >> That is a simple "named constant" or I prefer a "named >> literal".(string literal, number, compound) > > This is what I've been advocating here for years. But people seem to > prefer using a combination of #define, enum, const. At least you put in a "seem". It seems that way to you, but it seems to me that people use what C has, and to extrapolate from that to what they would prefer is step too far. > They especially seem keen on 'const', which is a read-only attribute > for variables. And you have a problem with that? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 16:41 +0100 |
| Message-ID | <tenvg5$p7n$1@gioia.aioe.org> |
| In reply to | #167374 |
On 31/08/2022 15:15, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 31/08/2022 13:48, Thiago Adams wrote:
>
>>> That is a simple "named constant" or I prefer a "named
>>> literal".(string literal, number, compound)
>>
>> This is what I've been advocating here for years. But people seem to
>> prefer using a combination of #define, enum, const.
>
> At least you put in a "seem". It seems that way to you, but it seems to
> me that people use what C has, and to extrapolate from that to what they
> would prefer is step too far.
The subthread is partly about the introduction of 'constexpr'. So
finally an opportunity to add what C has long lacked, but instead it's
taken one of C++'s hairy features and just cut it down.
>> They especially seem keen on 'const', which is a read-only attribute
>> for variables.
>
> And you have a problem with that?
Yes. You don't get named constants by emulating them with read-only
variables, that's just crass. And it lets you do this:
const int abc = 123;
*(int*)&abc = 999;
printf("abc = %d\n", abc);
It tells me that 'abc' is 999; so much for being a named constant, or
read-only!
'constexpr' seems just a way to continue using const variables, but
allowing their values to be used as compile-time expressions.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-31 08:55 -0700 |
| Message-ID | <47a6401a-f291-4a52-92df-51f1467954f7n@googlegroups.com> |
| In reply to | #167382 |
On Wednesday, August 31, 2022 at 12:42:14 PM UTC-3, Bart wrote:
...
> 'constexpr' seems just a way to continue using const variables, but
> allowing their values to be used as compile-time expressions.
Yes.
But const in C++ also could be used in compile-time expressions. (case, arrays, templates...)
There are few differences:
struct X {int i;};
constexpr struct X x = {1};
static_assert(x.i == 1);
changing constexpr for const it does not compile
but
const int i = 2;
static_assert(i == 2);
compiles.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-31 17:43 +0100 |
| Message-ID | <87h71spdn3.fsf@bsb.me.uk> |
| In reply to | #167382 |
Bart <bc@freeuk.com> writes:
> On 31/08/2022 15:15, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 31/08/2022 13:48, Thiago Adams wrote:
>>
>>>> That is a simple "named constant" or I prefer a "named
>>>> literal".(string literal, number, compound)
>>>
>>> This is what I've been advocating here for years. But people seem to
>>> prefer using a combination of #define, enum, const.
>> At least you put in a "seem". It seems that way to you, but it seems to
>> me that people use what C has, and to extrapolate from that to what they
>> would prefer is step too far.
>
> The subthread is partly about the introduction of 'constexpr'. So
> finally an opportunity to add what C has long lacked, but instead it's
> taken one of C++'s hairy features and just cut it down.
Eh? You said "people seem to prefer using a combination of #define,
enum, const". I disagreed. I don't see the connection.
>>> They especially seem keen on 'const', which is a read-only attribute
>>> for variables.
>>
>> And you have a problem with that?
>
> Yes. You don't get named constants by emulating them with read-only
> variables, that's just crass.
Oh I see. You mean const is not what you want it to be. I thought you
objected to marking objects as read only.
> const int abc = 123;
> *(int*)&abc = 999;
>
> printf("abc = %d\n", abc);
>
> It tells me that 'abc' is 999; so much for being a named constant, or
> read-only!
Don't you have a compiler that will tell you that such code is junk?
(It won't say so in so many words. Compiler writers are more polite
than I am!)
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web