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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 15:19 +0200 |
| Message-ID | <tenn5p$1qnca$1@dont-email.me> |
| In reply to | #167365 |
On 31/08/2022 13:50, Bart wrote: > On 31/08/2022 09:44, David Brown wrote: >> On 31/08/2022 01:43, Bart wrote: > >>> Your comments point to this behaviour: >>> >>> const int abc; // C: always exports >>> const int abc; // C++: never exports >>> static const int abc; // C: never exports >>> >>> This does not inspire confidence! >> >> static const int abc = 123; // Always internal linkage >> extern const int def = 456; // Always external linkage >> >> const int x = 123; // "static" in C++, "extern" in C. >> >> If you need confidence, learn the rules - look for patterns and >> reasoning, rather than assuming everything is flawed. You are not >> stupid - stop pretending this is too complicated for you. > > It /is/ flawed. You mention elsewhere that you don't consider PL design > as 'art'; I can believe that if you think so highly of C++. I never said any such thing about programming language design. Please try to read what I write, and not what you imagine I write because it suits your arguments. (Feel free to re-read my posts, including my recent reply to Anton that uses the word "art", and try again at understanding what I write.) > > I think that aesthetics plays an important part, and being clean, tidy, > orthogonal can help. I agree. Let's be clear here - I agree that in designing a /new/ programming language, it is a good thing to make concepts clear and orthogonal. But we are /not/ designing a new programming language - we are looking at a real, existing programming language that has evolved over a long time, that almost never throws anything away (backwards compatibility is key in the world of C), and that sometimes gains new features. We are considering whether the language has the features needed to make constants with various characteristics that programmers find useful. The answer is a resounding "yes". We are considering whether the new "constexpr" feature improves the language. The answer, again, is "yes". There is no doubt that in a new, clean, modern programming language you would have fewer ways to make constants, and fewer overlaps between the methods. You'd still have different methods for different purposes, but you'd probably keep concepts such as linkage, scope, lifetime, and initialisation orthogonal. But C23 is not a new language, and introducing a new feature does not mean existing features can be dropped.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-28 16:51 -0700 |
| Message-ID | <874jxwj5ay.fsf@nosuchdomain.example.com> |
| In reply to | #167252 |
David Brown <david.brown@hesbynett.no> writes:
[...]
>> On Friday, August 26, 2022 at 5:56:39 PM UTC-3, Keith Thompson wrote:
[...]
>>> Personally, I'm very glad C is getting constexpr.
>>
>
> Me too. I might have preferred making const variables a bit more like
> C++, but I'm quite happy with constexpr (I know where to find C++ when
> I want it). It will make it easier when you have things that are
> known fixed values at compile time, but you can't use them in the same
> way as you can use "integer constants" or literals.
I prefer constexpr to the C++ hack of making const mean "compile-time
constant" in some special-case circumstances. Admittedly it was a very
useful hack (and it was introduced before constexpr was available).
"const" really means "read-only" (and probably should have been spelled
that way). I like the (more or less clear) distinction between "const"
meaning "read-only" and "constexpr" meaning "compile-time constant".
--
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-08-29 09:45 +0200 |
| Message-ID | <tehqrg$vuvb$1@dont-email.me> |
| In reply to | #167270 |
On 29/08/2022 01:51, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >>> On Friday, August 26, 2022 at 5:56:39 PM UTC-3, Keith Thompson wrote: > [...] >>>> Personally, I'm very glad C is getting constexpr. >>> >> >> Me too. I might have preferred making const variables a bit more like >> C++, but I'm quite happy with constexpr (I know where to find C++ when >> I want it). It will make it easier when you have things that are >> known fixed values at compile time, but you can't use them in the same >> way as you can use "integer constants" or literals. > > I prefer constexpr to the C++ hack of making const mean "compile-time > constant" in some special-case circumstances. Admittedly it was a very > useful hack (and it was introduced before constexpr was available). > > "const" really means "read-only" (and probably should have been spelled > that way). I like the (more or less clear) distinction between "const" > meaning "read-only" and "constexpr" meaning "compile-time constant". > I believe that if that distinction had been clear from the start, I would definitely agree with you. Now, due to the history of the languages, it is inevitable that there is a certain degree of overlap in usage. But with "constexpr" in the language, it is possible to make the distinction in our source code even if the language is not clear. C++ has the added complication of constexpr functions - which might be evaluated at compile time, and might be evaluated at run time. This has led to "consteval" functions that are /definitely/ evaluated at compile time, and "constinit" to insist that a variable is statically initialised. (And of course, the compiler can do compile-time evaluation of anything whose value it knows is unchanging, regardless of any specifiers.) It's a bit of a mess - I'm glad that C23 is keeping it simple here. Perhaps, however, C23's "constexpr" is actually closer to C++20's "constinit" ?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-29 10:04 +0200 |
| Message-ID | <tehrv1$101hs$1@dont-email.me> |
| In reply to | #167284 |
On 29/08/2022 09:45, David Brown wrote: > On 29/08/2022 01:51, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>>> On Friday, August 26, 2022 at 5:56:39 PM UTC-3, Keith Thompson wrote: >> [...] >>>>> Personally, I'm very glad C is getting constexpr. >>>> >>> >>> Me too. I might have preferred making const variables a bit more like >>> C++, but I'm quite happy with constexpr (I know where to find C++ when >>> I want it). It will make it easier when you have things that are >>> known fixed values at compile time, but you can't use them in the same >>> way as you can use "integer constants" or literals. >> >> I prefer constexpr to the C++ hack of making const mean "compile-time >> constant" in some special-case circumstances. Admittedly it was a very >> useful hack (and it was introduced before constexpr was available). >> >> "const" really means "read-only" (and probably should have been spelled >> that way). I like the (more or less clear) distinction between "const" >> meaning "read-only" and "constexpr" meaning "compile-time constant". >> > > I believe that if that distinction had been clear from the start, I > would definitely agree with you. Now, due to the history of the > languages, it is inevitable that there is a certain degree of overlap in > usage. But with "constexpr" in the language, it is possible to make the > distinction in our source code even if the language is not clear. > > C++ has the added complication of constexpr functions - which might be > evaluated at compile time, and might be evaluated at run time. This has > led to "consteval" functions that are /definitely/ evaluated at compile > time, and "constinit" to insist that a variable is statically > initialised. (And of course, the compiler can do compile-time > evaluation of anything whose value it knows is unchanging, regardless of > any specifiers.) It's a bit of a mess - I'm glad that C23 is keeping it > simple here. > > Perhaps, however, C23's "constexpr" is actually closer to C++20's > "constinit" ? Scratch that last comment. All static lifetime data in C is already "constinit".
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-29 04:59 -0700 |
| Message-ID | <2f38674d-81b0-417d-9fe9-d5abc2fcfc3bn@googlegroups.com> |
| In reply to | #167284 |
On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote: ... > Perhaps, however, C23's "constexpr" is actually closer to C++20's > "constinit" ? I did not know about C++20 constinit. It sounds like a joke for all the ways to define a constant in C++, but it's not a joke.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-08-29 07:32 -0700 |
| Message-ID | <9f24d0cb-eca1-4bf3-a323-7cefb32e370an@googlegroups.com> |
| In reply to | #167294 |
On Monday, 29 August 2022 at 14:59:55 UTC+3, Thiago Adams wrote: > On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote: > ... > > Perhaps, however, C23's "constexpr" is actually closer to C++20's > > "constinit" ? > I did not know about C++20 constinit. It sounds like a joke for all the ways to > define a constant in C++, but it's not a joke. Yes ... last serious C++ version was C++14 after that it felt like competition of who can joke more and get more obscure garbage into language or more reasonable things erased from language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-29 16:47 +0200 |
| Message-ID | <teijh8$14cpj$1@dont-email.me> |
| In reply to | #167294 |
On 29/08/2022 13:59, Thiago Adams wrote: > On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote: > ... >> Perhaps, however, C23's "constexpr" is actually closer to C++20's >> "constinit" ? > > I did not know about C++20 constinit. It sounds like a joke for all the ways to > define a constant in C++, but it's not a joke. > It's easy to mock things we don't understand. Just because /you/ don't see the need of a feature in /your/ programming, does not mean it is not useful to others. "constinit" asks the compiler to ensure that the statically allocated object is initialised with constant data before main() and before any runtime initialisation functions or constructors are run. It avoids the complications of ordering static initialisations, or the overhead of initialising function static objects when the function is first run. "constinit int x = 123;" does not define a constant - it says that the /initialisation/ of x is constant. You can think of "constinit" as meaning "constexpr but not const", or that "constexpr" (for variables) means "constinit const". C does not need "constinit" because all initialisations of statically allocated objects are constant in C. (I have not yet moved to C++20, so I was not sure of the working of "constinit" and had to look it up.)
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2022-08-29 17:51 -0700 |
| Message-ID | <39f810b7-0146-402b-9f21-374299576709n@googlegroups.com> |
| In reply to | #167298 |
On Monday, 29 August 2022 at 15:47:18 UTC+1, David Brown wrote: > On 29/08/2022 13:59, Thiago Adams wrote: > > On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote: > > ... > >> Perhaps, however, C23's "constexpr" is actually closer to C++20's > >> "constinit" ? > > > > I did not know about C++20 constinit. It sounds like a joke for all the ways to > > define a constant in C++, but it's not a joke. > > > It's easy to mock things we don't understand. Just because /you/ don't > see the need of a feature in /your/ programming, does not mean it is not > useful to others. ... > (I have not yet moved to C++20, so I was not sure of the working of > "constinit" and had to look it up.) So you haven't yet used that feature yourself, but are telling everyone else they need it! I read your explanation a couple of times, but still didn't get it. (I sense a broader issue of initialisation order of data in different modules when that is semi-automatic, but to comment on it would require me to draw on my own experience, which is verboten.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-30 13:15 +0200 |
| Message-ID | <tekrfu$1f4lr$1@dont-email.me> |
| In reply to | #167311 |
On 30/08/2022 02:51, bart c wrote:
> On Monday, 29 August 2022 at 15:47:18 UTC+1, David Brown wrote:
>> On 29/08/2022 13:59, Thiago Adams wrote:
>>> On Monday, August 29, 2022 at 4:46:08 AM UTC-3, David Brown wrote:
>>> ...
>>>> Perhaps, however, C23's "constexpr" is actually closer to C++20's
>>>> "constinit" ?
>>>
>>> I did not know about C++20 constinit. It sounds like a joke for all the ways to
>>> define a constant in C++, but it's not a joke.
>>>
>> It's easy to mock things we don't understand. Just because /you/ don't
>> see the need of a feature in /your/ programming, does not mean it is not
>> useful to others.
> ...
>> (I have not yet moved to C++20, so I was not sure of the working of
>> "constinit" and had to look it up.)
>
>
> So you haven't yet used that feature yourself, but are telling everyone else they need it!
Why do you claim I am "telling everyone else they need it" ? Nothing I
wrote could possibly be interpreted that way. Enough people see a
potential use (not necessity) for it to make it worth adding to the
language. Time will tell if it becomes popular or not.
>
> I read your explanation a couple of times, but still didn't get it.
>
(Being C++, this is really off-topic for c.l.c., but it might be of
interest to people here.)
In C++, you can write at file scope :
int fib(int a) {
if (a < 2) return 1;
return fib(a - 1) + fib(a - 2);
}
int x = fib(5);
int y = fib(40);
The compiler may choose, as an optimisation, to pre-compute "fib(5)" and
use constant initialisation equivalent to "int x = 8;", so that the
memory for the variable "x" gets loaded with the value 8 before main()
or any other "real" code of the program runs. (You are familiar with
this initialisation procedure from C.)
But for y, and optionally for x, the compiler will use run-time
initialisation. In effect, it generates "int y;" and a code section
that executes "y = fib(40);" and is run pre-main.
Sometimes you don't want the possibility of having such run-time
initialisation, with all its potential complications such as startup
time, initialisation order, protection against race conditions for
function-local statics called from multiple threads, etc. But given the
code above, you cannot easily tell which, if either, of the variable
initialisations is done with a simple constant copy.
To solve this, you first have to add "constexpr" to the "fib" function.
That tells the compiler that if it is given a constant expression
argument, the function can be evaluated at compile time to give a
constant expression result (while also still being usable at runtime -
"consteval" is the alternative to say that the function is compile-time
only and can never be used at runtime). This places certain
restrictions on the function - it has to be "pure", at least for the
particular constant values that you use in the program, but that's fine
here.
Next, you label the variables as "constinit". This tells the compiler
that these functions must be initialised as constants, or compilation
will fail :
constexpr int fib(int a) {
if (a < 2) return 1;
return fib(a - 1) + fib(a - 2);
}
constinit int x = fib(5);
constinit int y = fib(40);
Now the compiler has no choice but to treat this as "int x = 8;" and
"int y = 165580141;". If the compiler can't do the calculation at
compile time (such as if I'd written fib(46), which at 2971215073
overflows a 32-bit int, or fib(41) which exceeds gcc's standard limit of
the number of steps it allows in a compile-time execution), then the
compiler halts with an error.
So "constinit" gives you tighter control of such initialisation. Note
that the variables "x" and "y" are still variables - it is only the
initialisation that is done by a constant, they are not constants
themselves (as they would be with "constexpr int x = fib(5);". Indeed,
the line "constinit int x = fib(5);" is equivalent to :
constexpr int x_init = fib(5);
int x = x_init;
> (I sense a broader issue of initialisation order of data in different modules when that is semi-automatic, but to comment on it would require me to draw on my own experience, which is verboten.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-30 14:58 +0100 |
| Message-ID | <tel51m$j95$1@gioia.aioe.org> |
| In reply to | #167328 |
On 30/08/2022 12:15, David Brown wrote:
> On 30/08/2022 02:51, bart c wrote:
> (Being C++, this is really off-topic for c.l.c., but it might be of
> interest to people here.)
>
>
> In C++, you can write at file scope :
>
> int fib(int a) {
> if (a < 2) return 1;
> return fib(a - 1) + fib(a - 2);
> }
>
>
> int x = fib(5);
> int y = fib(40);
>
>
> The compiler may choose, as an optimisation, to pre-compute "fib(5)" and
> use constant initialisation equivalent to "int x = 8;", so that the
> memory for the variable "x" gets loaded with the value 8 before main()
> or any other "real" code of the program runs. (You are familiar with
> this initialisation procedure from C.)
>
> But for y, and optionally for x, the compiler will use run-time
> initialisation. In effect, it generates "int y;" and a code section
> that executes "y = fib(40);" and is run pre-main.
>
> Sometimes you don't want the possibility of having such run-time
> initialisation, with all its potential complications such as startup
> time, initialisation order, protection against race conditions for
> function-local statics called from multiple threads, etc. But given the
> code above, you cannot easily tell which, if either, of the variable
> initialisations is done with a simple constant copy.
>
> To solve this, you first have to add "constexpr" to the "fib" function.
> That tells the compiler that if it is given a constant expression
> argument, the function can be evaluated at compile time to give a
> constant expression result (while also still being usable at runtime -
> "consteval" is the alternative to say that the function is compile-time
> only and can never be used at runtime). This places certain
> restrictions on the function - it has to be "pure", at least for the
> particular constant values that you use in the program, but that's fine
> here.
>
> Next, you label the variables as "constinit". This tells the compiler
> that these functions must be initialised as constants, or compilation
> will fail :
>
> constexpr int fib(int a) {
> if (a < 2) return 1;
> return fib(a - 1) + fib(a - 2);
> }
>
> constinit int x = fib(5);
> constinit int y = fib(40);
>
>
> Now the compiler has no choice but to treat this as "int x = 8;" and
> "int y = 165580141;". If the compiler can't do the calculation at
> compile time (such as if I'd written fib(46), which at 2971215073
> overflows a 32-bit int, or fib(41) which exceeds gcc's standard limit of
> the number of steps it allows in a compile-time execution), then the
> compiler halts with an error.
>
>
> So "constinit" gives you tighter control of such initialisation. Note
> that the variables "x" and "y" are still variables - it is only the
> initialisation that is done by a constant, they are not constants
> themselves (as they would be with "constexpr int x = fib(5);". Indeed,
> the line "constinit int x = fib(5);" is equivalent to :
>
> constexpr int x_init = fib(5);
> int x = x_init;
OK, thanks.
So 'constinit' means something should be evaluated before execution
(where there is a choice or possibility that it can be done after
execution starts, although I can still see problems where x, y, z refer
to each other, but only one or two use constinit).
And 'constexpr' treats them as readonly, but also allows such an
expression to be considered a guaranteed compile-time expression, unlike
static const, suitable for fixed arrays, switch cases, and for constant
reduction.
Yet, you also say constexpr expressions can have their address taken,
and can use up storage, which is quite unlike a #define constant
(earlier you had equated these two).
So with between const, constinit, constexpr (plus enum and #define),
with all their subtle differences, it is still not that clear, and there
still isn't ONE feature that is a named constant, pure and simple.
I'm not allowed to mention my stuff, but I'm referring to one that works
like 'enum', but specifically intended for arbitrary named scalar values
of a dominated type.
Now that I've briefly reinstated a proper newsreader, I can show my
earlier table in full; the columns show Yes when the desired attribute
is True:
#define enum const constexpr
Uses normal scope rules No Yes Yes Yes
Won't create VLAs Yes Yes No? ?
Can't take their address Yes Yes No No?
Cannot modify Yes Yes Yes Yes?
Can be used in switch cases Yes Yes No Yes?
Can be reduced in expressions Yes Yes ?? Yes?
Can have any scalar type Yes? No Yes Yes
Can be used for static data init Yes Yes No Yes?
Not dependent on compiler Yes Yes No Yes?
Uses storage No No Yes? Yes?
Value not context dependent No Yes Yes Yes
(Last entry is new; for #define X = A+B, the value of X depends on the
local values of A, B, whatever they are; it is not determined once at
the point of definition.
'Use storage' is from the language's POV; target instruction sets may
not support immediate operands for all types, and are forced to use
memory, but this applies also to literals like 123.456.)
Notice the right-hand two columns either have lots of Nos, or lots of
question marks. The ideal feature will have solid Yeses.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-30 15:54 +0100 |
| Message-ID | <tel8ap$903$1@gioia.aioe.org> |
| In reply to | #167332 |
On 30/08/2022 14:58, Bart wrote:
> Now that I've briefly reinstated a proper newsreader, I can show my
> earlier table in full; the columns show Yes when the desired attribute
> is True:
>
> #define enum const constexpr
>
> Uses normal scope rules No Yes Yes Yes
> Won't create VLAs Yes Yes No? ?
> Can't take their address Yes Yes No No?
> Cannot modify Yes Yes Yes Yes?
> Can be used in switch cases Yes Yes No Yes?
> Can be reduced in expressions Yes Yes ?? Yes?
> Can have any scalar type Yes? No Yes Yes
> Can be used for static data init Yes Yes No Yes?
> Not dependent on compiler Yes Yes No Yes?
> Uses storage No No Yes? Yes?
I forgot this needs to have the opposite sense; that line should be:
Doesn't use storage Yes Yes No? No?
(I also forgot Usenet doesn't allow editing.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2022-08-30 09:17 -0700 |
| Message-ID | <b72cd4b1-9d56-4fce-9529-4c7843462611n@googlegroups.com> |
| In reply to | #167334 |
On Tuesday, August 30, 2022 at 11:54:30 AM UTC-3, Bart wrote: > On 30/08/2022 14:58, Bart wrote: > > > Now that I've briefly reinstated a proper newsreader, I can show my > > earlier table in full; the columns show Yes when the desired attribute > > is True: > > > > #define enum const constexpr > > > > Uses normal scope rules No Yes Yes Yes > > Won't create VLAs Yes Yes No? ? > > Can't take their address Yes Yes No No? > > Cannot modify Yes Yes Yes Yes? > > Can be used in switch cases Yes Yes No Yes? > > Can be reduced in expressions Yes Yes ?? Yes? > > Can have any scalar type Yes? No Yes Yes > > Can be used for static data init Yes Yes No Yes? > > Not dependent on compiler Yes Yes No Yes? > > Uses storage No No Yes? Yes? > I forgot this needs to have the opposite sense; that line should be: > > Doesn't use storage Yes Yes No? No? > > (I also forgot Usenet doesn't allow editing.) You table is considering the case of integers and floating. For instance "Can't take their address" , " Uses storage " for define, it depends of the type.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-30 18:34 +0100 |
| Message-ID | <telhmk$pi6$1@gioia.aioe.org> |
| In reply to | #167341 |
On 30/08/2022 17:17, Thiago Adams wrote:
> On Tuesday, August 30, 2022 at 11:54:30 AM UTC-3, Bart wrote:
>> On 30/08/2022 14:58, Bart wrote:
>>
>>> Now that I've briefly reinstated a proper newsreader, I can show my
>>> earlier table in full; the columns show Yes when the desired attribute
>>> is True:
>>>
>>> #define enum const constexpr
>>>
>>> Uses normal scope rules No Yes Yes Yes
>>> Won't create VLAs Yes Yes No? ?
>>> Can't take their address Yes Yes No No?
>>> Cannot modify Yes Yes Yes Yes?
>>> Can be used in switch cases Yes Yes No Yes?
>>> Can be reduced in expressions Yes Yes ?? Yes?
>>> Can have any scalar type Yes? No Yes Yes
>>> Can be used for static data init Yes Yes No Yes?
>>> Not dependent on compiler Yes Yes No Yes?
>>> Uses storage No No Yes? Yes?
>> I forgot this needs to have the opposite sense; that line should be:
>>
>> Doesn't use storage Yes Yes No? No?
>>
>> (I also forgot Usenet doesn't allow editing.)
>
> You table is considering the case of integers and floating.
>
> For instance
> "Can't take their address" , " Uses storage " for define, it depends of the type.
For me this is about named constants, usually numeric literals (although
some of my characteristics only only to integer types).
So given:
constant A = 1234;
constant B = 97.1;
where 'constant' is a feature that has a solid Yes in every column of my
chart, I want the behaviour of:
A, B
in source code to be exactly the same as though I'd written 1234, 97.1.
When you look at open source code, there are huge numbers of #defines
for such integer types; it doesn't even use enums.
In a language like C, there aren't many other types of literals. Perhaps
nilptr now, and string literals ('A' literals are basically integers).
String literals are already readonly (or should be), but they
necessarily have an address, since you can't do much with them otherwise.
(In my own work, the equivalent of `constant S = "ABC";` doesn't allow
`&S`, and doesn't allow an `S = "DEF"` assignment.
In C, it all depends:
&S S = "DEF"
#define S "ABC"; Yes No (due to wrong type)
const char* S = "ABC; Yes Yes
You're still grappling with features that only do half the job.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 11:25 +0200 |
| Message-ID | <ten9e9$1p8n2$1@dont-email.me> |
| In reply to | #167344 |
On 30/08/2022 19:34, Bart wrote:
> On 30/08/2022 17:17, Thiago Adams wrote:
>> On Tuesday, August 30, 2022 at 11:54:30 AM UTC-3, Bart wrote:
>>> On 30/08/2022 14:58, Bart wrote:
>>>
>>>> Now that I've briefly reinstated a proper newsreader, I can show my
>>>> earlier table in full; the columns show Yes when the desired attribute
>>>> is True:
>>>>
>>>> #define enum const constexpr
>>>>
>>>> Uses normal scope rules No Yes Yes Yes
>>>> Won't create VLAs Yes Yes No? ?
>>>> Can't take their address Yes Yes No No?
>>>> Cannot modify Yes Yes Yes Yes?
>>>> Can be used in switch cases Yes Yes No Yes?
>>>> Can be reduced in expressions Yes Yes ?? Yes?
>>>> Can have any scalar type Yes? No Yes Yes
>>>> Can be used for static data init Yes Yes No Yes?
>>>> Not dependent on compiler Yes Yes No Yes?
>>>> Uses storage No No Yes? Yes?
>>> I forgot this needs to have the opposite sense; that line should be:
>>>
>>> Doesn't use storage Yes Yes No? No?
>>>
>>> (I also forgot Usenet doesn't allow editing.)
>>
>> You table is considering the case of integers and floating.
>>
>> For instance
>> "Can't take their address" , " Uses storage " for define, it depends
>> of the type.
>
>
> For me this is about named constants, usually numeric literals (although
> some of my characteristics only only to integer types).
>
> So given:
>
> constant A = 1234;
> constant B = 97.1;
>
> where 'constant' is a feature that has a solid Yes in every column of my
> chart, I want the behaviour of:
>
> A, B
>
> in source code to be exactly the same as though I'd written 1234, 97.1.
Ah, so you want C pre-processor macros. Problem solved.
>
> When you look at open source code, there are huge numbers of #defines
> for such integer types; it doesn't even use enums.
Different people have different styles, and macros are quite an
effective and practical way to get such constants. Some people use
"enum" for them, but others limit their use of "enum" for things that
really are an enumeration, or at least for a range of constants that are
logically grouped.
>
> In a language like C, there aren't many other types of literals. Perhaps
> nilptr now, and string literals ('A' literals are basically integers).
>
There are also compound literals in C, which can be very useful (C++
does not support them, which some people find disappointing).
#include <stdio.h>
#include <stdbool.h>
typedef struct Point { int a; int b; } Point;
extern void foo(Point * pnt);
void bar(void) {
foo(&(Point) { 1, 2 });
}
void print_maybe(bool b) {
printf((const char* []) { "No", "Yes"}[b]);
}
void print_maybe2(bool b) {
const char* ss[] = { "No", "Yes" };
printf(ss[b]);
}
<https://en.cppreference.com/w/c/language/compound_literal>
> String literals are already readonly (or should be), but they
> necessarily have an address, since you can't do much with them otherwise.
>
> (In my own work, the equivalent of `constant S = "ABC";` doesn't allow
> `&S`, and doesn't allow an `S = "DEF"` assignment.
>
> In C, it all depends:
>
> &S S = "DEF"
>
> #define S "ABC"; Yes No (due to wrong type)
> const char* S = "ABC; Yes Yes
>
> You're still grappling with features that only do half the job.)
>
const char * const S = "ABC" Yes No
const char S[] = "ABC" Yes No
You /can/ take their address, but you generally do not need to. There
are plenty of options in C depending on what you want to do at the time.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 14:14 +0100 |
| Message-ID | <tenmqo$fs7$1@gioia.aioe.org> |
| In reply to | #167362 |
On 31/08/2022 10:25, David Brown wrote:
> On 30/08/2022 19:34, Bart wrote:
>> For me this is about named constants, usually numeric literals
>> (although some of my characteristics only only to integer types).
>>
>> So given:
>>
>> constant A = 1234;
>> constant B = 97.1;
>>
>> where 'constant' is a feature that has a solid Yes in every column of
>> my chart, I want the behaviour of:
>>
>> A, B
>>
>> in source code to be exactly the same as though I'd written 1234, 97.1.
>
> Ah, so you want C pre-processor macros. Problem solved.
I'm not sure how serious you're being here. #define macros have a few
well-known problems:
#define M (a + b)
(1) 'M' does not obey normal scope rules. This means for example you
can't have any other identifier - function, variable, parameter,
enum, type (I think not even a tag) - also called M
(2) M's 'value' is not bound to it at the point of definition. Its
value will be whatever 'a' and 'b' happen to be at the point invoked.
They might not even be numbers
(3) Following on from (2), if the value is a complex expression, that
will be re-evaluated at each point of invocation, which is just
inefficient (but as a C++ guy, you will not see anything wrong with
that)
(4) There is no type associated with M. Although casts could be used,
these are rare in practice. So, also following from (2), the type
of the invocation and resulting behaviour can vary
(5) C convention likes macro names to be in capitals. This makes the
appearance of such code untidy.
I think that's about it as far as C is concerned. But venturing outside
of C (I know you hate this), then given a named constant as I normally
use them, it can be trivially exported, imported, accessed within name
spaces, all the things can be done with /any/ user-defined entity.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 15:28 +0200 |
| Message-ID | <tennmr$1qp1h$1@dont-email.me> |
| In reply to | #167368 |
On 31/08/2022 15:14, Bart wrote: > On 31/08/2022 10:25, David Brown wrote: >> On 30/08/2022 19:34, Bart wrote: > >>> For me this is about named constants, usually numeric literals >>> (although some of my characteristics only only to integer types). >>> >>> So given: >>> >>> constant A = 1234; >>> constant B = 97.1; >>> >>> where 'constant' is a feature that has a solid Yes in every column of >>> my chart, I want the behaviour of: >>> >>> A, B >>> >>> in source code to be exactly the same as though I'd written 1234, 97.1. >> >> Ah, so you want C pre-processor macros. Problem solved. > > I'm not sure how serious you're being here. You want way to make "named constants" that act exactly as though you'd written the value directly in the source. Macros give you that: #define A 1234 #define B 97.1 There. Done. Sure, you can do more with macros than just that - both more useful things, and more mistakes. But that is irrelevant for the task at hand, which is now solved. > #define macros have a few > well-known problems: > > #define M (a + b) > > (1) 'M' does not obey normal scope rules. This means for example you > can't have any other identifier - function, variable, parameter, > enum, type (I think not even a tag) - also called M > There is a trick to handling that - it is called "pick sensible names for your identifiers when programming". > (2) M's 'value' is not bound to it at the point of definition. Its > value will be whatever 'a' and 'b' happen to be at the point invoked. > They might not even be numbers > That is an advantage or a disadvantage, depending on the situation. Since you are talking about constants here, "a" and "b" will also be constants, and there is no problem. Even better for your preferences, they can be defined /after/ the definition of M (though they must still be defined before the use of M). > (3) Following on from (2), if the value is a complex expression, that > will be re-evaluated at each point of invocation, which is just > inefficient (but as a C++ guy, you will not see anything wrong with > that) That's what you get when you ask for textual substitution. Or is this a case of being careful what you wish for, because you might get it? > > (4) There is no type associated with M. Although casts could be used, > these are rare in practice. So, also following from (2), the type > of the invocation and resulting behaviour can vary > That is an advantage or a disadvantage, depending on the code. That's a great thing about C - with different ways to make your named constants, you get to choose what works best at the time. > (5) C convention likes macro names to be in capitals. This makes the > appearance of such code untidy. > The great thing about conventions is that they are just conventions. If you don't like all-caps identifiers (I don't), don't use them for your macro names (I don't). > I think that's about it as far as C is concerned. But venturing outside > of C (I know you hate this), then given a named constant as I normally > use them, it can be trivially exported, imported, accessed within name > spaces, all the things can be done with /any/ user-defined entity. And yet somehow, the whole computing world has been built in C quite successfully.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-08-31 15:02 +0100 |
| Message-ID | <tenplh$1shb$1@gioia.aioe.org> |
| In reply to | #167370 |
On 31/08/2022 14:28, David Brown wrote:
> On 31/08/2022 15:14, Bart wrote:
>> On 31/08/2022 10:25, David Brown wrote:
>>> On 30/08/2022 19:34, Bart wrote:
>>
>>>> For me this is about named constants, usually numeric literals
>>>> (although some of my characteristics only only to integer types).
>>>>
>>>> So given:
>>>>
>>>> constant A = 1234;
>>>> constant B = 97.1;
>>>>
>>>> where 'constant' is a feature that has a solid Yes in every column
>>>> of my chart, I want the behaviour of:
>>>>
>>>> A, B
>>>>
>>>> in source code to be exactly the same as though I'd written 1234, 97.1.
>>>
>>> Ah, so you want C pre-processor macros. Problem solved.
>>
>> I'm not sure how serious you're being here.
>
> You want way to make "named constants" that act exactly as though you'd
> written the value directly in the source. Macros give you that:
>
> #define A 1234
> #define B 97.1
>
> There. Done.
If someone wants to avoid the issues with #define, then none of enum,
const, constexpr will do that.
(Say, for example, they want to define A and B locally within a
function. Given that everyone here seems so keen on keeping scopes
absolutely minimal by only declaring things within the nearest {} block,
it is actually astonishing that you see no issue with only having a
single file-wide scope for named literals.)
> Sure, you can do more with macros than just that - both more useful
> things, and more mistakes. But that is irrelevant for the task at hand,
> which is now solved.
>
>
>> #define macros have a few well-known problems:
>>
>> #define M (a + b)
>>
>> (1) 'M' does not obey normal scope rules. This means for example you
>> can't have any other identifier - function, variable, parameter,
>> enum, type (I think not even a tag) - also called M
>>
>
> There is a trick to handling that - it is called "pick sensible names
> for your identifiers when programming".
OK, so we don't need scopes at all. Just pick sensible names that don't
clash with anything else since each must be unique across a program.
These are C macro names.
>
>> (2) M's 'value' is not bound to it at the point of definition. Its
>> value will be whatever 'a' and 'b' happen to be at the point invoked.
>> They might not even be numbers
>>
>
> That is an advantage or a disadvantage, depending on the situation.
> Since you are talking about constants here, "a" and "b" will also be
> constants, and there is no problem.
enum {width = 100, height = 12};
#define ratio (width/height)
double a = ratio;
{
double width=42;
double b = ratio;
printf("A = %f, B = %f\n", a, b);
}
Here, the macro 'ratio' is evaluated two different ways (8.0 and 3.5).
> The great thing about conventions is that they are just conventions. If
> you don't like all-caps identifiers (I don't), don't use them for your
> macro names (I don't).
Sure, in my code. Most code I see isn't mine.
>
>> I think that's about it as far as C is concerned. But venturing
>> outside of C (I know you hate this), then given a named constant as I
>> normally use them, it can be trivially exported, imported, accessed
>> within name spaces, all the things can be done with /any/ user-defined
>> entity.
>
> And yet somehow, the whole computing world has been built in C quite
> successfully.
It could probably have been built in assembly on machine code. HLLs are
supposed to make things easier, more maintainable, and less error prone.
The bad choices in C (still there 50 years on as there STILL isn't
simple named literal feature that ticks all the boxes; constexpr is just
a different set) have made it harder than it ought to.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-31 15:28 +0100 |
| Message-ID | <87v8q8qygb.fsf@bsb.me.uk> |
| In reply to | #167370 |
David Brown <david.brown@hesbynett.no> writes: > On 31/08/2022 15:14, Bart wrote: >> On 31/08/2022 10:25, David Brown wrote: >>> On 30/08/2022 19:34, Bart wrote: >> >>>> For me this is about named constants, usually numeric literals (although some of my characteristics only only to integer types). >>>> >>>> So given: >>>> >>>> constant A = 1234; >>>> constant B = 97.1; >>>> >>>> where 'constant' is a feature that has a solid Yes in every column of my chart, I want the behaviour of: >>>> >>>> A, B >>>> >>>> in source code to be exactly the same as though I'd written 1234, 97.1. >>> >>> Ah, so you want C pre-processor macros. Problem solved. > >> I'm not sure how serious you're being here. > > You want way to make "named constants" that act exactly as though you'd written the value directly in the source. Macros give you that: > > #define A 1234 > #define B 97.1 > > There. Done. I can tell you are getting frustrated, but take a moment... Do you really think that macros give the programmer what they need? The macro processor was a quick fix to provide quasi-modules and almost named constants, but it's for from ideal for either use. 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 17:06 +0200 |
| Message-ID | <tentcp$1rc5n$1@dont-email.me> |
| In reply to | #167375 |
On 31/08/2022 16:28, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 31/08/2022 15:14, Bart wrote: >>> On 31/08/2022 10:25, David Brown wrote: >>>> On 30/08/2022 19:34, Bart wrote: >>> >>>>> For me this is about named constants, usually numeric literals (although some of my characteristics only only to integer types). >>>>> >>>>> So given: >>>>> >>>>> constant A = 1234; >>>>> constant B = 97.1; >>>>> >>>>> where 'constant' is a feature that has a solid Yes in every column of my chart, I want the behaviour of: >>>>> >>>>> A, B >>>>> >>>>> in source code to be exactly the same as though I'd written 1234, 97.1. >>>> >>>> Ah, so you want C pre-processor macros. Problem solved. >> >>> I'm not sure how serious you're being here. >> >> You want way to make "named constants" that act exactly as though you'd written the value directly in the source. Macros give you that: >> >> #define A 1234 >> #define B 97.1 >> >> There. Done. > > I can tell you are getting frustrated, but take a moment... Do you > really think that macros give the programmer what they need? The macro > processor was a quick fix to provide quasi-modules and almost named > constants, but it's for from ideal for either use. As I see it, macros are one of many useful tools in the C toolbox. They have their disadvantages, and I personally prefer to use other constructs such as "static const", "enum", or static inline functions for many situations where macros might traditionally have been popular. But they also have their advantages for some uses. Like many powerful tools, they are great when used well, but can cause trouble when misused. 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. > > 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. I have been trying to help Bart by explaining some of the features of different types of "named constants" in C and C++, since he appears to misunderstand many of them. (He does not claim to know much C++, AFAIK, though that does not limit his opinions on the language!) I believe and hope that I have helped him a little there. But he does seem to have gone from "I don't understand what constexpr does", which can be answered usefully, back to his old "C is terrible and my language is brilliant" posts. Yes, it is frustrating.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-08-31 15:29 +0000 |
| Message-ID | <X7LPK.25$479c.10@fx48.iad> |
| In reply to | #167379 |
David Brown <david.brown@hesbynett.no> writes: >On 31/08/2022 16:28, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 31/08/2022 15:14, Bart wrote: >>>> On 31/08/2022 10:25, David Brown wrote: >>>>> On 30/08/2022 19:34, Bart wrote: >>>> >>>>>> For me this is about named constants, usually numeric literals (although some of my characteristics only only to integer types). >>>>>> >>>>>> So given: >>>>>> >>>>>> constant A = 1234; >>>>>> constant B = 97.1; >>>>>> >>>>>> where 'constant' is a feature that has a solid Yes in every column of my chart, I want the behaviour of: >>>>>> >>>>>> A, B >>>>>> >>>>>> in source code to be exactly the same as though I'd written 1234, 97.1. >>>>> >>>>> Ah, so you want C pre-processor macros. Problem solved. >>> >>>> I'm not sure how serious you're being here. >>> >>> You want way to make "named constants" that act exactly as though you'd written the value directly in the source. Macros give you that: >>> >>> #define A 1234 >>> #define B 97.1 >>> >>> There. Done. >> >> I can tell you are getting frustrated, but take a moment... Do you >> really think that macros give the programmer what they need? The macro >> processor was a quick fix to provide quasi-modules and almost named >> constants, but it's for from ideal for either use. > >As I see it, macros are one of many useful tools in the C toolbox. They >have their disadvantages, and I personally prefer to use other >constructs such as "static const", "enum", or static inline functions >for many situations where macros might traditionally have been popular. > But they also have their advantages for some uses. Like many powerful >tools, they are great when used well, but can cause trouble when misused. Classic useful examples are the various "for_each" macros in Linux, such as for_each_process(), for_each_input_queue(), etc.
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web