Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #82003 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2021-10-21 05:23 +0000 |
| Last post | 2021-10-24 14:20 +0000 |
| Articles | 20 on this page of 179 — 23 participants |
Back to article view | Back to comp.lang.c++
I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 05:23 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-21 08:54 +0200
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 09:48 +0000
Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-21 12:55 +0300
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-21 12:57 +0200
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 13:40 +0000
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-21 15:04 +0100
Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-21 16:41 +0200
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 14:57 +0000
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 14:51 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-21 12:09 -0400
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-21 23:49 +0100
Re: I think references should have been const by default "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-10-21 16:21 -0700
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 16:14 +0100
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-22 12:04 -0700
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 20:47 +0100
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-22 13:29 -0700
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 11:54 +0200
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 11:22 +0100
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 12:35 +0200
Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-23 13:23 +0100
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 13:57 +0100
Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-23 21:02 +0100
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-23 15:07 -0700
Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-23 21:15 -0700
Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-23 21:12 -0700
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-22 11:13 +0200
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-22 19:18 -0400
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:41 +0000
Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-23 21:30 +0100
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 04:51 +0000
Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-26 00:53 +0100
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-22 09:46 +0200
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 15:48 +0100
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 12:21 +0200
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 12:06 +0100
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 18:45 +0200
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 18:58 +0100
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-24 12:11 +0200
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-24 23:11 +0100
Re: I think references should have been const by default Öö Tiib <ootiib@hot.ee> - 2021-10-24 16:18 -0700
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 00:58 +0100
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 08:21 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 09:47 +0000
Re: I think references should have been const by default Bo Persson <bo@bo-persson.se> - 2021-10-25 12:33 +0200
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 14:19 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:59 -0400
Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-25 17:56 +0200
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 11:11 -0700
Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-26 17:15 +0200
Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:41 -0700
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 16:14 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 13:14 -0400
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:18 +0000
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 12:39 +0100
Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-26 14:29 +0100
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 15:11 +0100
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 09:49 -0700
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 18:38 +0100
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 11:20 -0700
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 20:32 +0100
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 22:18 +0200
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:43 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 08:29 +0200
Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:32 -0700
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:12 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-11-01 08:53 +0100
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-01 11:26 -0400
Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-11-02 16:19 +0100
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-02 12:54 -0400
Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-11-02 23:49 +0200
Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-11-03 00:38 +0100
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:36 +0000
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 15:55 +0100
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:26 +0000
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 20:35 +0100
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:44 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:27 -0400
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:31 -0400
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:42 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:22 -0400
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:30 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:23 -0400
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:51 -0400
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 14:34 -0400
Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-26 12:57 -0700
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-27 07:57 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 08:47 +0000
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 14:29 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-28 05:17 +0000
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:30 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 04:47 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 05:11 +0000
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-29 08:40 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:15 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 11:07 +0200
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 14:30 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 17:30 +0200
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:46 +0000
Re: I think references should have been const by default scott@slp53.sl.home (Scott Lurndal) - 2021-10-27 16:13 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 11:39 -0400
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:51 +0000
Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-27 17:21 +0100
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:29 +0000
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-28 11:20 +0100
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 12:26 -0400
Re: I think references should have been const by default Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2021-10-31 09:22 -0700
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-01 00:13 -0400
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-28 05:20 +0000
Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-27 23:10 -0700
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:30 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 04:51 +0000
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-29 08:39 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:34 +0000
Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-27 17:41 +0100
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 19:02 +0200
Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-27 18:21 +0100
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 11:38 -0400
Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:49 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 12:36 -0400
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:57 +0000
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 18:19 +0100
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 10:48 -0700
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:21 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 08:37 +0000
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 09:02 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 11:14 +0000
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:35 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 05:01 +0000
Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:34 -0700
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:43 -0400
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:21 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 22:32 +0200
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 05:04 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:42 -0400
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:48 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:52 -0400
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 10:22 -0700
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 10:27 -0700
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 14:06 -0400
Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:45 -0700
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-29 11:11 -0700
Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 07:39 -0700
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-25 10:59 -0700
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:29 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 08:53 +0200
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:23 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 08:40 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:18 +0000
Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 09:07 +0200
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:03 -0400
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:39 -0400
Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 10:56 -0700
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:30 -0400
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 14:39 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 11:05 -0400
Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-25 12:45 -0700
Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-26 11:20 -0700
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 05:00 +0000
Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 12:13 +0100
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:36 +0000
Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-25 16:58 +0200
Re: I think references should have been const by default "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-10-22 12:28 -0700
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 09:12 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 09:52 +0000
Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 10:36 +0000
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:45 +0000
Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-21 12:07 -0400
Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-21 12:18 +0300
Re: I think references should have been const by default Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:13 +0200
Re: I think references should have been const by default Bo Persson <bo@bo-persson.se> - 2021-10-21 15:08 +0200
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:45 +0000
Re: I think references should have been const by default Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-22 07:55 +0200
Re: I think references should have been const by default Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-22 11:21 +0000
Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-21 13:22 +0200
Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:48 +0000
Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-21 13:57 +0200
Re: I think references should have been const by default Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 21:27 +0000
Re: I think references should have been const by default Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-10-24 14:20 +0000
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-10-23 13:23 +0100 |
| Message-ID | <871r4c3p7f.fsf@bsb.me.uk> |
| In reply to | #82044 |
David Brown <david.brown@hesbynett.no> writes:
> I think it is odd, however, that you can have qualified types in the
> generic association list, since they can't ever match anything
> (AFAICS).
I was curious so I tried this:
#include <stdio.h>
struct S { const int i; } s;
struct S f(void) { return s; }
int main(void)
{
const char *t =
_Generic(f().i,
int: "int",
const int: "const int");
puts(t);
}
f().i is not a lvalue and has a const-qualified type. gcc prints "int",
but clang prints "const int". I think clang is right here. (So much
for "they all copy gcc"!)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-23 13:57 +0100 |
| Message-ID | <sl10rt$u3f$1@dont-email.me> |
| In reply to | #82049 |
On 23/10/2021 13:23, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> I think it is odd, however, that you can have qualified types in the
>> generic association list, since they can't ever match anything
>> (AFAICS).
>
> I was curious so I tried this:
>
> #include <stdio.h>
>
> struct S { const int i; } s;
> struct S f(void) { return s; }
>
> int main(void)
> {
> const char *t =
> _Generic(f().i,
> int: "int",
> const int: "const int");
> puts(t);
> }
>
> f().i is not a lvalue and has a const-qualified type. gcc prints "int",
> but clang prints "const int". I think clang is right here. (So much
> for "they all copy gcc"!)
You need to file a bug report to Clang's developers so that they can fix
that oversight!
But, why do think Clang is wrong? The type has a top-level const qualifier.
I don't get why this is only removed for an lvalue (where you'd think
that a const attribute is more critical).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-10-23 21:02 +0100 |
| Message-ID | <87v91n33y9.fsf@bsb.me.uk> |
| In reply to | #82050 |
Bart <bc@freeuk.com> writes:
> On 23/10/2021 13:23, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> I think it is odd, however, that you can have qualified types in the
>>> generic association list, since they can't ever match anything
>>> (AFAICS).
>> I was curious so I tried this:
>> #include <stdio.h>
>> struct S { const int i; } s;
>> struct S f(void) { return s; }
>> int main(void)
>> {
>> const char *t =
>> _Generic(f().i,
>> int: "int",
>> const int: "const int");
>> puts(t);
>> }
>> f().i is not a lvalue and has a const-qualified type. gcc prints "int",
>> but clang prints "const int". I think clang is right here. (So much
>> for "they all copy gcc"!)
>
> You need to file a bug report to Clang's developers so that they can
> fix that oversight!
>
> But, why do think Clang is wrong? The type has a top-level const
> qualifier.
I said I think clang is right (because the expression f().i is not an
lvalue).
> I don't get why this is only removed for an lvalue (where you'd think
> that a const attribute is more critical).
lvalue conversion converts an lvalue to the value stored. It makes no
sense for the result to have any qualifiers -- they are anything but
critical for pure values.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-10-23 15:07 -0700 |
| Message-ID | <87mtmz2y5n.fsf@nosuchdomain.example.com> |
| In reply to | #82050 |
Bart <bc@freeuk.com> writes:
> On 23/10/2021 13:23, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> I think it is odd, however, that you can have qualified types in the
>>> generic association list, since they can't ever match anything
>>> (AFAICS).
>> I was curious so I tried this:
>> #include <stdio.h>
>> struct S { const int i; } s;
>> struct S f(void) { return s; }
>> int main(void)
>> {
>> const char *t =
>> _Generic(f().i,
>> int: "int",
>> const int: "const int");
>> puts(t);
>> }
>> f().i is not a lvalue and has a const-qualified type. gcc prints
>> "int",
>> but clang prints "const int". I think clang is right here. (So much
>> for "they all copy gcc"!)
>
> You need to file a bug report to Clang's developers so that they can
> fix that oversight!
>
> But, why do think Clang is wrong? The type has a top-level const qualifier.
>
> I don't get why this is only removed for an lvalue (where you'd think
> that a const attribute is more critical).
The removal of type qualifiers is part of lvalue conversion. No lvalue,
no lvalue conversion.
I can see that it would make sense for the expression `f().i` to have
type int rather than const int, but the standard doesn't say so.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-23 21:15 -0700 |
| Message-ID | <86y26jgise.fsf@linuxsc.com> |
| In reply to | #82055 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Bart <bc@freeuk.com> writes:
>
>> On 23/10/2021 13:23, Ben Bacarisse wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> I think it is odd, however, that you can have qualified types in the
>>>> generic association list, since they can't ever match anything
>>>> (AFAICS).
>>>
>>> I was curious so I tried this:
>>> #include <stdio.h>
>>> struct S { const int i; } s;
>>> struct S f(void) { return s; }
>>> int main(void)
>>> {
>>> const char *t =
>>> _Generic(f().i,
>>> int: "int",
>>> const int: "const int");
>>> puts(t);
>>> }
>>> f().i is not a lvalue and has a const-qualified type. gcc prints
>>> "int",
>>> but clang prints "const int". I think clang is right here. (So much
>>> for "they all copy gcc"!)
>>
>> You need to file a bug report to Clang's developers so that they can
>> fix that oversight!
>>
>> But, why do think Clang is wrong? The type has a top-level const qualifier.
>>
>> I don't get why this is only removed for an lvalue (where you'd think
>> that a const attribute is more critical).
>
> The removal of type qualifiers is part of lvalue conversion. No lvalue,
> no lvalue conversion.
>
> I can see that it would make sense for the expression `f().i` to have
> type int rather than const int, but the standard doesn't say so.
There is some confusion about that. More info in comp.std.c.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-23 21:12 -0700 |
| Message-ID | <8635orhxho.fsf@linuxsc.com> |
| In reply to | #82049 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I was curious so I tried this:
>
> #include <stdio.h>
>
> struct S { const int i; } s;
> struct S f(void) { return s; }
>
> int main(void)
> {
> const char *t =
> _Generic(f().i,
> int: "int",
> const int: "const int");
> puts(t);
> }
>
> f().i is not a lvalue and has a const-qualified type. gcc prints "int",
> but clang prints "const int". I think clang is right here. (So much
> for "they all copy gcc"!)
I have looked into this question and just now posted in comp.std.c
giving the results of my investigation.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-22 11:13 +0200 |
| Message-ID | <sktvc3$7gr$1@dont-email.me> |
| In reply to | #82024 |
On 21/10/2021 18:09, James Kuyper wrote: > On Thu, 21 Oct 2021 15:04:19 +0100 > Bart <bc@freeuk.com> wrote: > ... >> I don't about C++, but in C, you can take a program, remove all the >> 'const' qualifiers, and it will still compile and work. >> >> Makes you think... > > Keep in mind that this is strictly true in C only if you remove all the > "const" qualifiers from all of the #included header files, and you can't > do that with standard library headers. It would also be difficult to do > with the headers associated with third-party libraries. > I'm not suggesting that this would be at all a good idea, and it would certainly be undefined and undocumented behaviour, but you could probably remove "const" by adding "-Dconst=" to your compiler flags. It works for gcc (maybe I should file a bug here - it is even accepted with -std=c99 -Wpedantic).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-22 19:18 -0400 |
| Message-ID | <skvgrp$tsj$1@dont-email.me> |
| In reply to | #82035 |
On 10/22/21 5:13 AM, David Brown wrote: ... > I'm not suggesting that this would be at all a good idea, and it would > certainly be undefined and undocumented behaviour, but you could > probably remove "const" by adding "-Dconst=" to your compiler flags. It > works for gcc (maybe I should file a bug here - it is even accepted with > -std=c99 -Wpedantic). > You are right - the behavior would be undefined: "The program shall not have any macros with names lexically identical to keywords currently defined prior to the inclusion of the header or when any macro defined in the header is expanded." (C standard, 7.1.2p5) As a "shall" occurring outside of a "Constraints" section, the behavior of a program that violates that rule is undefined (4p2). But it would probably work as intended on many implementations.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-22 04:41 +0000 |
| Message-ID | <sktfe9$1i4k$1@gioia.aioe.org> |
| In reply to | #82018 |
Bart <bc@freeuk.com> wrote: > I don't about C++, but in C, you can take a program, remove all the > 'const' qualifiers, and it will still compile and work. At least if you turn off warnings. Also, you'll likely make some programs less efficient because the compiler will do compile-time calculations on things like const arrays containing compile-time literals, which it won't if the array is not const. So yes, 'const' can actually make the program more efficient (especially in C++, where it guarantees to the compiler that it can assume the contents won't change).
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-10-23 21:30 +0100 |
| Message-ID | <20211023213039.936a11b6492e7e771c4fd481@cvine--nospam--.freeserve.co.uk> |
| In reply to | #82028 |
On Fri, 22 Oct 2021 04:41:47 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: > So yes, 'const' can actually make the program more efficient (especially > in C++, where it guarantees to the compiler that it can assume the > contents won't change). Since this thread is entitled "I think references should have been const by default", it may be worth mentioning that holding a const reference to an object does not mean that the compiler "can assume the contents won't change". It guarantees that, in the absence of a const cast, non-mutable non-static data won't be modified through the reference. If the object concerned is a lvalue it says nothing about what might be done to the object's non-mutable data through its variable name (assuming that is non-const) or by some other non-const reference. It also says nothing about the mutability of the object's static data (if any). I say this in case it is used to put forward the incorrect notion that "const" means "thread safe", which I have occasionally seen propagated by the ill-informed.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-25 04:51 +0000 |
| Message-ID | <sl5d4l$15ko$1@gioia.aioe.org> |
| In reply to | #82054 |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: > I say this in case it is used to put forward the incorrect notion that > "const" means "thread safe", which I have occasionally seen propagated > by the ill-informed. "const means thread-safe" is not said in the context of const references, but in the context of const member functions, which is a completely different thing. (And, in this case, the idea is "const member functions *should be* re-entrant", rather than "const member functions are thread-safe".) And when I said "const can make the program more efficient" I'm referring to compile-time literals. Especially ones in a const array. (When the compiler sees the definition of a const array full of compile-time literals, it can assume that the contents of the array will never change, and can start taking values from it at compile time if it's able to. It doesn't need to assume that the values may change.)
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-10-26 00:53 +0100 |
| Message-ID | <20211026005326.52478b6e568ba6d22954c530@cvine--nospam--.freeserve.co.uk> |
| In reply to | #82063 |
On Mon, 25 Oct 2021 04:51:35 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote: > > I say this in case it is used to put forward the incorrect notion that > > "const" means "thread safe", which I have occasionally seen propagated > > by the ill-informed. > > "const means thread-safe" is not said in the context of const references, > but in the context of const member functions, which is a completely > different thing. I think you are confused: the two go together. Where a const reference references an object, the only member functions of the object that you may call via that reference are const ones. const member functions are not thread safe in the general case. If you are suggesting otherwise you are wrong. > (And, in this case, the idea is "const member functions *should be* > re-entrant", rather than "const member functions are thread-safe".) No, I was referring to misguided suggestions as to the latter. > And when I said "const can make the program more efficient" I'm > referring to compile-time literals. That _is_ a completely different thing: compilers can certainly make assumptions about literals. > Especially ones in a const > array. (When the compiler sees the definition of a const array > full of compile-time literals, it can assume that the contents > of the array will never change, and can start taking values from > it at compile time if it's able to. It doesn't need to assume > that the values may change.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-22 09:46 +0200 |
| Message-ID | <sktq8m$7ht$1@dont-email.me> |
| In reply to | #82018 |
On 21/10/2021 16:04, Bart wrote: > On 21/10/2021 14:40, RacingRabbit@watershipdown.co.uk wrote: >> On Thu, 21 Oct 2021 12:57:05 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >>> On 21/10/2021 11:48, Juha Nieminen wrote: >>>> David Brown <david.brown@hesbynett.no> wrote: >>>>> I agree with you entirely. But if we are going for wishful thinking >>>>> about how C++ could have been made better, I'd have preferred "const" >>>>> for all variables and required "mutable" to declare a variable that >>>>> could be modified. (Of course that would mean you'd need something >>>>> else >>>>> for class members that are today "mutable". But I think it's a lot >>>>> more >>>>> common for people to make variables that could have been "const" but >>>>> aren't, than to use mutable members.) >>>> >>>> That would quite quickly turn quite annoying, eg. with things like >>>> for-loops: >>>> >>>> for(int i = 0; i < 10; ++i) // error, i is const >>>> >>> >>> for (mutable int i = 0; i < 10; ++i) >>> >>> Yes, there are many places where you want variable variables - but I >>> think overall you typically have more that could be declared const than >>> have to be variable. (The idea is not without precedence - there are >>> other modern languages with constant objects by default.) >>> >>> For loops, I think the best solution would be a mixture - the loop >>> variable should be mutable within the controlling expressions, but >>> should be constant within the statement or block - as though you had >>> written: >> >> I think const is a lot of fuss about nothing frankly. I barely use them >> anyway and I can't remember the last time that I had a bug due to >> updating >> a variable that shouldn't have been updated. For those who think its >> simply >> an indication to other devs that a variable won't be changed then fair >> enough >> but personally I find a lot of const/non const compilation errors related >> to functions a PITA. >> > > I don't about C++, but in C, you can take a program, remove all the > 'const' qualifiers, and it will still compile and work. > > Makes you think... > I makes you think that it is true that good programming language design is more about what you /can't/ do, rather than about what you /can/ do. "const" in C does not let you do things you could not otherwise do - it restricts you, thus making code clearer, safer, more maintainable, and perhaps sometimes more efficient. Const in C++ is more integral to the language, and can't be removed in the same way (not that anyone would want to).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-22 15:48 +0100 |
| Message-ID | <skuj0p$t60$1@dont-email.me> |
| In reply to | #82034 |
On 22/10/2021 08:46, David Brown wrote: > On 21/10/2021 16:04, Bart wrote: >> I don't [know] about C++, but in C, you can take a program, remove all the >> 'const' qualifiers, and it will still compile and work. >> >> Makes you think... >> > > I makes you think that it is true that good programming language design > is more about what you /can't/ do, rather than about what you /can/ do. > "const" in C does not let you do things you could not otherwise do - it > restricts you, thus making code clearer, safer, more maintainable, and > perhaps sometimes more efficient. There are better ways of doing it. In C, it is just adds a lot of clutter that effects readability and can hide real problems. Neither does the syntax make it that obvious which bit of the type is refered to, as in: const int * const * x; The first const applies to the following int; the second const refers to the /previous/ * (AIUI). This can give a false sense of security, especially when you have, say, a const pointer to a struct which contains non-const pointers. The 'const' only protects that top level; it does not stop you writing nested non-const data. In my example, x can still be written to! (x=0 is allowed; but *x=0 and **x=0 are not.) Use of 'const' can also proliferate through interactions with non-const versions of the type, adding to the clutter. (I don't do much with readonly stuff [in my languages]. My experiments focus on mutability of objects, or specific variables, not of types.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-23 12:21 +0200 |
| Message-ID | <sl0nmu$bn3$1@dont-email.me> |
| In reply to | #82037 |
On 22/10/2021 16:48, Bart wrote: > On 22/10/2021 08:46, David Brown wrote: >> On 21/10/2021 16:04, Bart wrote: > >>> I don't [know] about C++, but in C, you can take a program, remove >>> all the >>> 'const' qualifiers, and it will still compile and work. >>> >>> Makes you think... >>> >> >> I makes you think that it is true that good programming language design >> is more about what you /can't/ do, rather than about what you /can/ do. >> "const" in C does not let you do things you could not otherwise do - it >> restricts you, thus making code clearer, safer, more maintainable, and >> perhaps sometimes more efficient. > > There are better ways of doing it. There are certainly /different/ ways of doing things. There are lots of different programming languages, with their different strengths and weaknesses. > In C, it is just adds a lot of > clutter that effects readability and can hide real problems. What an odd idea. If you don't like "const", don't use it in your programming. Others find it useful to aid readability and avoid problems. > > Neither does the syntax make it that obvious which bit of the type is > refered to, as in: > > const int * const * x; If you find this kind of thing confusing, use "typedef". It exists to improve readability (amongst other benefits). > > The first const applies to the following int; the second const refers to > the /previous/ * (AIUI). > > This can give a false sense of security, especially when you have, say, > a const pointer to a struct which contains non-const pointers. The > 'const' only protects that top level; it does not stop you writing > nested non-const data. > You mean, people who don't really understand what they are doing and write code that confuses themselves, get mixed up? And how is C different from any other language in that respect? I appreciate that you personally prefer a different ordering when writing types, and that you are not alone in that. Fine. C has a different ordering, and people usually manage perfectly well. The difference between "const int * x", "int * const x" and "const int * const x" is one of these things newbies to C often find hard, and it turns up in every FAQ and tutorial on the language. If /you/ still find it hard, read a FAQ. > In my example, x can still be written to! (x=0 is allowed; but *x=0 and > **x=0 are not.) Yes - x is not const. > > Use of 'const' can also proliferate through interactions with non-const > versions of the type, adding to the clutter. > > (I don't do much with readonly stuff [in my languages]. My experiments > focus on mutability of objects, or specific variables, not of types.) >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-23 12:06 +0100 |
| Message-ID | <sl0qcj$sub$1@dont-email.me> |
| In reply to | #82045 |
On 23/10/2021 11:21, David Brown wrote: > On 22/10/2021 16:48, Bart wrote: >> On 22/10/2021 08:46, David Brown wrote: >>> On 21/10/2021 16:04, Bart wrote: >> >>>> I don't [know] about C++, but in C, you can take a program, remove >>>> all the >>>> 'const' qualifiers, and it will still compile and work. >>>> >>>> Makes you think... >>>> >>> >>> I makes you think that it is true that good programming language design >>> is more about what you /can't/ do, rather than about what you /can/ do. >>> "const" in C does not let you do things you could not otherwise do - it >>> restricts you, thus making code clearer, safer, more maintainable, and >>> perhaps sometimes more efficient. >> >> There are better ways of doing it. > > There are certainly /different/ ways of doing things. There are lots of > different programming languages, with their different strengths and > weaknesses. > >> In C, it is just adds a lot of >> clutter that effects readability and can hide real problems. > > What an odd idea. > > If you don't like "const", don't use it in your programming. Others > find it useful to aid readability and avoid problems. I was thinking more about other people's code. Mine doesn't use const at all. >> >> Neither does the syntax make it that obvious which bit of the type is >> refered to, as in: >> >> const int * const * x; > > If you find this kind of thing confusing, use "typedef". It exists to > improve readability (amongst other benefits). So, even /more/ clutter?! I's also like to see a typedefed version of my example that is not harder to understand. >> >> The first const applies to the following int; the second const refers to >> the /previous/ * (AIUI). >> >> This can give a false sense of security, especially when you have, say, >> a const pointer to a struct which contains non-const pointers. The >> 'const' only protects that top level; it does not stop you writing >> nested non-const data. >> > > You mean, people who don't really understand what they are doing and > write code that confuses themselves, get mixed up? And how is C > different from any other language in that respect? Yes, everybody. You have a dynamic tree data structure for example, using non-const references within its nodes to allow it to be updated. How do you write a function that takes a reference to that tree, but is not allowed to update it? This is what someone might expect of an immutable parameter. This is not to say that I know how to achieve this; I don't (but I haven't researched it much either). The nearest I can do is pass a deep copy of such a tree, to protect the original, but that is hardly efficient. I just see C's const as a waste of time. I'm starting to use readonly data in a few places without my languages, but where it's handled sensibly. What I don't do is introduce such a polarising type attribute at every level of a data structure, one that poisons every other type it comes into contact with, such that it becomes challenging to do perfectly innocuous things.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-23 18:45 +0200 |
| Message-ID | <sl1e73$sl7$1@dont-email.me> |
| In reply to | #82048 |
On 23/10/2021 13:06, Bart wrote: > On 23/10/2021 11:21, David Brown wrote: >> On 22/10/2021 16:48, Bart wrote: >>> On 22/10/2021 08:46, David Brown wrote: >>>> On 21/10/2021 16:04, Bart wrote: >>> >>>>> I don't [know] about C++, but in C, you can take a program, remove >>>>> all the >>>>> 'const' qualifiers, and it will still compile and work. >>>>> >>>>> Makes you think... >>>>> >>>> >>>> I makes you think that it is true that good programming language design >>>> is more about what you /can't/ do, rather than about what you /can/ do. >>>> "const" in C does not let you do things you could not otherwise >>>> do - it >>>> restricts you, thus making code clearer, safer, more maintainable, and >>>> perhaps sometimes more efficient. >>> >>> There are better ways of doing it. >> >> There are certainly /different/ ways of doing things. There are lots of >> different programming languages, with their different strengths and >> weaknesses. >> >>> In C, it is just adds a lot of >>> clutter that effects readability and can hide real problems. >> >> What an odd idea. >> >> If you don't like "const", don't use it in your programming. Others >> find it useful to aid readability and avoid problems. > > I was thinking more about other people's code. Mine doesn't use const at > all. Perhaps if you used more of C's common features yourself, you'd be less confused about them and less inclined to think they are "clutter" or hinder readability. (If you only want to use C as an output language from your transpilers, and thus only use a subset of the language, then that's absolutely fine - but it makes you a poor judge of what features are useful to people working with human-written C code rather than machine-generated C code.) > >>> >>> Neither does the syntax make it that obvious which bit of the type is >>> refered to, as in: >>> >>> const int * const * x; >> >> If you find this kind of thing confusing, use "typedef". It exists to >> improve readability (amongst other benefits). > > So, even /more/ clutter?! I's also like to see a typedefed version of my > example that is not harder to understand. > typedef const int constant_integer; typedef constant_integer * pointer_to_constant_integer; typedef const pointer_to_constant_integer constant_pointer_to_constant_integer; typedef constant_pointer_to_constant_integer * pointer_to_constant_pointer_to_constant_integer; pointer_to_constant_pointer_to_constant_integer x; That's the order you prefer, is it not? (I'm not suggesting it's a good way to write it, I'm merely showing you how it could be done with a choice of names that might suit your liking.) Maybe you want it more compact: typedef const int * p_cint; typedef const p_cint * p_cp_cint; p_cp_cint x; In real code, of course, it would usually make more sense to think about what your types actually are and how they will be used, and then use type names that fit. >>> >>> The first const applies to the following int; the second const refers to >>> the /previous/ * (AIUI). >>> >>> This can give a false sense of security, especially when you have, say, >>> a const pointer to a struct which contains non-const pointers. The >>> 'const' only protects that top level; it does not stop you writing >>> nested non-const data. >>> >> >> You mean, people who don't really understand what they are doing and >> write code that confuses themselves, get mixed up? And how is C >> different from any other language in that respect? > > Yes, everybody. You have a dynamic tree data structure for example, > using non-const references within its nodes to allow it to be updated. > > How do you write a function that takes a reference to that tree, but is > not allowed to update it? > > This is what someone might expect of an immutable parameter. There are occasions when it is more convenient to cast away const, or where it is hard to maintain full const correctness. "const" does not absolve the programmer of having to think. But it does make a lot of code clearer and easier to understand. > > This is not to say that I know how to achieve this; I don't (but I > haven't researched it much either). The nearest I can do is pass a deep > copy of such a tree, to protect the original, but that is hardly efficient. > > I just see C's const as a waste of time. I'm starting to use readonly > data in a few places without my languages, but where it's handled sensibly. > > What I don't do is introduce such a polarising type attribute at every > level of a data structure, one that poisons every other type it comes > into contact with, such that it becomes challenging to do perfectly > innocuous things. > Nobody does that with "const". I guess it is just yet another of C's features that you don't quite understand, and prefer to hate irrationally than learn.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-23 18:58 +0100 |
| Message-ID | <sl1igc$qvn$1@dont-email.me> |
| In reply to | #82051 |
On 23/10/2021 17:45, David Brown wrote:
> On 23/10/2021 13:06, Bart wrote:
>>>> const int * const * x;
>>>
>>> If you find this kind of thing confusing, use "typedef". It exists to
>>> improve readability (amongst other benefits).
>>
>> So, even /more/ clutter?! I's also like to see a typedefed version of my
>> example that is not harder to understand.
>>
>
> typedef const int constant_integer;
> typedef constant_integer * pointer_to_constant_integer;
> typedef const pointer_to_constant_integer
> constant_pointer_to_constant_integer;
> typedef constant_pointer_to_constant_integer *
> pointer_to_constant_pointer_to_constant_integer;
>
> pointer_to_constant_pointer_to_constant_integer x;
>
>
> That's the order you prefer, is it not? (I'm not suggesting it's a good
> way to write it, I'm merely showing you how it could be done with a
> choice of names that might suit your liking.)
>
>
> Maybe you want it more compact:
>
> typedef const int * p_cint;
> typedef const p_cint * p_cp_cint;
> p_cp_cint x;
Well, I was right, the alternatives are worse.
If you are interested in the actual type, or the 'shape' of that type,
devoid of qualifiers, then you don't want all that. You want to know the
type is 'int**'.
>> This is what someone might expect of an immutable parameter.
>
> There are occasions when it is more convenient to cast away const, or
> where it is hard to maintain full const correctness. "const" does not
> absolve the programmer of having to think. But it does make a lot of
> code clearer and easier to understand.
Somebody writes an informal library but doesn't bother to mark with
'const' those functions that take char* that don't happen to modify the
string:
void f1(char*);
void f2(char*);
void f3(char*);
Now someone who has a mania for 'const' wants to use it:
const char* s="ABC";
f1(s);
However, it doesn't work. They will know from the specs that f1 doesn't
write into the string, but the compiler doesn't know that.
Now, it starts to get messy. Either casts have to be inserted, or the
library needs to be heavily revised. Then that library may import
another which is also missing consts. And so const-poisoning infects the
whole code-base.
At some point, it will also stop you doing things legally, and you have
to start using casts. Now, you are starting to fight the language.
Was it Pascal or Ada that first had those in/out parameter attributes?
I can write this [in my syntax]:
proc f1(ichar s) = {} # anything goes
proc f2(ichar in s) = {} # s is input to the function
proc f3(ichar out s) = {} # s is output from the function
I don't do anything with these at the minute (I think 'out' and 'inout',
not shown, are just aliases for '&') but they can do a lot just as
annotations.
At some point an implementation can enforce them and ensure that an 'in'
data structure is not modified in the function, even one that has
mutable components. The programmer doesn't need to micro-manage every
level of the type structure, or have to think about exactly how
foolproof those 'const' attributes are.
It should be like a write-protect switch on the whole caboodle.
(At least, within the bounds of what the language can help with. A data
structure may contain references to external data, such as files, disks,
images, which can all be modifible, or they can be altered via another
path to the original data.
But C's const doesn't prevent that either.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-24 12:11 +0200 |
| Message-ID | <sl3bg8$ce5$1@dont-email.me> |
| In reply to | #82052 |
On 23/10/2021 19:58, Bart wrote:
> On 23/10/2021 17:45, David Brown wrote:
>> On 23/10/2021 13:06, Bart wrote:
>
>>>>> const int * const * x;
>>>>
>>>> If you find this kind of thing confusing, use "typedef". It exists to
>>>> improve readability (amongst other benefits).
>>>
>>> So, even /more/ clutter?! I's also like to see a typedefed version of my
>>> example that is not harder to understand.
>>>
>>
>> typedef const int constant_integer;
>> typedef constant_integer * pointer_to_constant_integer;
>> typedef const pointer_to_constant_integer
>> constant_pointer_to_constant_integer;
>> typedef constant_pointer_to_constant_integer *
>> pointer_to_constant_pointer_to_constant_integer;
>>
>> pointer_to_constant_pointer_to_constant_integer x;
>>
>>
>> That's the order you prefer, is it not? (I'm not suggesting it's a good
>> way to write it, I'm merely showing you how it could be done with a
>> choice of names that might suit your liking.)
>>
>>
>> Maybe you want it more compact:
>>
>> typedef const int * p_cint;
>> typedef const p_cint * p_cp_cint;
>> p_cp_cint x;
>
>
> Well, I was right, the alternatives are worse.
>
> If you are interested in the actual type, or the 'shape' of that type,
> devoid of qualifiers, then you don't want all that. You want to know the
> type is 'int**'.
>
>
>>> This is what someone might expect of an immutable parameter.
>>
>> There are occasions when it is more convenient to cast away const, or
>> where it is hard to maintain full const correctness. "const" does not
>> absolve the programmer of having to think. But it does make a lot of
>> code clearer and easier to understand.
>
> Somebody writes an informal library but doesn't bother to mark with
> 'const' those functions that take char* that don't happen to modify the
> string:
>
> void f1(char*);
> void f2(char*);
> void f3(char*);
>
> Now someone who has a mania for 'const' wants to use it:
>
> const char* s="ABC";
> f1(s);
>
> However, it doesn't work. They will know from the specs that f1 doesn't
> write into the string, but the compiler doesn't know that.
>
> Now, it starts to get messy. Either casts have to be inserted, or the
> library needs to be heavily revised. Then that library may import
> another which is also missing consts. And so const-poisoning infects the
> whole code-base.
>
> At some point, it will also stop you doing things legally, and you have
> to start using casts. Now, you are starting to fight the language.
>
> Was it Pascal or Ada that first had those in/out parameter attributes?
>
> I can write this [in my syntax]:
>
> proc f1(ichar s) = {} # anything goes
> proc f2(ichar in s) = {} # s is input to the function
> proc f3(ichar out s) = {} # s is output from the function
>
> I don't do anything with these at the minute (I think 'out' and 'inout',
> not shown, are just aliases for '&') but they can do a lot just as
> annotations.
>
People can write code in a lazy way (or perhaps an old way), and this
can cause some inconveniences in using it along with code written in
newer and better ways. That's true in general - it is not special for
C, nor special for "const" in C.
Your solution to C's const problem (as you see it), is to have a
language where you can distinguish between pointers which cannot be used
to change the data, and pointers which /can/ be used to change the data.
As long as people use these correctly in your language, or Pascal, or
Ada, everything works correctly.
That's fine - and a good idea.
It is /exactly/ the same as is done in C. "void f1(char *)" is like an
"inout" parameter, and "void f2(const char *)" is like an "in" parameter.
Using "char *" as a parameter in C when it is read-only data is exactly
like using "inout" parameters in Ada or Pascal, or "ichar s" in your
language - it is lazy, unhelpful, and it stops people using it for
constant data (without extra effort).
Therefore, I simply don't understand what you have against "const" in C
- your own language is almost identical except for minor syntax differences.
(You do have a syntax for saying the pointer is used only for writing,
not for reading, which standard C is missing.)
> At some point an implementation can enforce them and ensure that an 'in'
> data structure is not modified in the function, even one that has
> mutable components. The programmer doesn't need to micro-manage every
> level of the type structure, or have to think about exactly how
> foolproof those 'const' attributes are.
>
> It should be like a write-protect switch on the whole caboodle.
>
> (At least, within the bounds of what the language can help with. A data
> structure may contain references to external data, such as files, disks,
> images, which can all be modifible, or they can be altered via another
> path to the original data.
>
> But C's const doesn't prevent that either.)
>
Yes, "const" has its limitations - the same ones as you have in your
language. Programming languages /always/ have compromises.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-24 23:11 +0100 |
| Message-ID | <sl4lmt$5jf$1@dont-email.me> |
| In reply to | #82058 |
On 24/10/2021 11:11, David Brown wrote: > On 23/10/2021 19:58, Bart wrote: >> I don't do anything with these at the minute (I think 'out' and 'inout', >> not shown, are just aliases for '&') but they can do a lot just as >> annotations. >> > > People can write code in a lazy way (or perhaps an old way), and this > can cause some inconveniences in using it along with code written in > newer and better ways. That's true in general - it is not special for > C, nor special for "const" in C. > > Your solution to C's const problem (as you see it), is to have a > language where you can distinguish between pointers which cannot be used > to change the data, and pointers which /can/ be used to change the data. > As long as people use these correctly in your language, or Pascal, or > Ada, everything works correctly. > > That's fine - and a good idea. > > It is /exactly/ the same as is done in C. "void f1(char *)" is like an > "inout" parameter, and "void f2(const char *)" is like an "in" parameter. > > Using "char *" as a parameter in C when it is read-only data is exactly > like using "inout" parameters in Ada or Pascal, or "ichar s" in your > language - it is lazy, unhelpful, and it stops people using it for > constant data (without extra effort). > > Therefore, I simply don't understand what you have against "const" in C > - your own language is almost identical except for minor syntax differences. I've played around with C-style readonly type attributes in the past. I didnt't like them. It disrupts the type system (see the fuss about how _Generic should work) and it didn't give the necessary protection. 'const' in C only affects one level of a complex type. It doesn't affects those parts not specified (like the members of a struct type, or rather those values at the other side of an embedded pointer type, which is not itself const). I want 'readonly' to protect an entire data structure, especially one that is otherwise mutable that is passed to a function, by only specifying one thing. Now, I haven't fully implemented such an attribute (I've only reserved syntax like 'let' and 'in'), I just know how I'd like it to work. That is, propagate down deep into the data structure. I think that is possible. I don't think it would be part of the type system; it's likely to be a property of an expression.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c++
csiph-web