Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #175828 > unrolled thread
| Started by | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| First post | 2023-09-18 01:21 +0300 |
| Last post | 2023-09-18 07:21 -0700 |
| Articles | 20 on this page of 195 — 17 participants |
Back to article view | Back to comp.lang.c
Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-18 01:21 +0300
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-18 01:23 +0300
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 00:32 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-09-18 10:55 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 13:40 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-18 06:02 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 17:10 +0200
Re: Do you insist on const-correctness? "comp.lang.c" <malcolm.arthur.mclean@gmail.com> - 2023-09-18 16:47 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 09:25 +0200
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-19 02:57 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:31 -0700
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-19 03:54 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 16:54 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:33 -0700
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-19 14:56 -0700
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-19 13:43 +0000
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 12:49 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 19:10 +0300
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-17 17:17 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-09-18 11:53 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 16:55 +0200
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-18 15:54 +0000
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 18:10 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-18 19:36 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 19:55 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-18 21:57 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 14:00 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 21:26 +0000
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 15:55 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 09:33 +0200
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 21:59 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-18 22:01 +0100
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 22:16 +0100
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 15:51 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 22:59 +0000
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 16:04 -0700
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 16:19 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 16:24 -0700
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 16:44 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 17:37 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 09:41 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-19 10:12 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 17:10 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-19 22:22 +0100
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-19 15:35 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 22:44 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-20 12:55 +0200
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 14:07 -0700
Re: Do you insist on const-correctness? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-19 00:13 -0400
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-19 09:57 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 16:37 +0200
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-19 16:55 +0000
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 15:16 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-18 20:31 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 14:03 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 14:04 -0700
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-18 22:26 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 15:59 -0700
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-19 00:37 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-19 12:26 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 17:15 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-19 11:00 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 17:01 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-23 16:35 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 19:13 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 10:38 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-23 19:05 +0300
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-23 18:45 +0100
Re: Do you insist on const-correctness? Richard Damon <Richard@Damon-Family.org> - 2023-09-23 14:24 -0400
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-24 17:05 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-24 23:26 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 08:43 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 11:51 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 15:40 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 18:56 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 11:03 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 19:53 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 11:55 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-25 20:08 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 21:29 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-25 12:42 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-25 21:11 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-26 08:55 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 00:22 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-26 15:03 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 14:37 +0300
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 14:57 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-26 17:21 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 13:49 +0100
Re: Do you insist on const-correctness? cross@spitfire.i.gajendra.net (Dan Cross) - 2023-09-26 13:57 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 17:14 +0300
Re: Do you insist on const-correctness? cross@spitfire.i.gajendra.net (Dan Cross) - 2023-09-26 14:27 +0000
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-26 15:22 +0000
Re: Do you insist on const-correctness? cross@spitfire.i.gajendra.net (Dan Cross) - 2023-09-26 17:45 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-26 17:10 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-26 08:29 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:04 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 03:37 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 17:03 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 08:35 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 18:52 +0200
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 10:46 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 20:26 +0200
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-27 11:45 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 21:19 +0200
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:34 -0700
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 01:11 +0100
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 19:32 +0100
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 17:12 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-28 01:49 +0100
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 17:53 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-28 11:21 +0100
Re: Do you insist on const-correctness? Psychedelics Haven <psychedelicshaven@gmail.com> - 2023-09-28 04:01 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:56 +0300
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 07:15 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 18:38 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-28 21:47 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 01:45 +0300
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-29 10:38 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 14:33 +0300
Re: Do you insist on const-correctness? Spiros Bousbouras <spibou@gmail.com> - 2023-09-29 12:10 +0000
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-29 05:28 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-29 15:19 +0100
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-29 15:18 +0100
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 02:18 -0700
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 18:04 -0700
[OT] missing evidence (Was: Do you insist on const-correctness?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 02:31 +0100
Re: [OT] missing evidence (Was: Do you insist on const-correctness?) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 21:02 -0700
Re: [OT] missing evidence (Was: Do you insist on const-correctness?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 21:48 -0700
Re: [OT] missing evidence (Was: Do you insist on const-correctness?) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-28 22:33 -0700
Re: [OT] missing evidence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 16:52 +0100
Re: [OT] missing evidence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-29 18:19 -0700
Re: [OT] missing evidence Anton Shepelev <anton.txt@gmail.moc> - 2023-09-30 13:06 +0300
Re: [OT] missing evidence David Brown <david.brown@hesbynett.no> - 2023-09-30 17:30 +0200
Re: [OT] missing evidence Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 00:33 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 17:13 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 00:50 +0300
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 14:19 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 14:21 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:29 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 16:32 -0700
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-28 21:24 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 23:05 +0300
Re: Do you insist on const-correctness? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-27 14:18 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 16:57 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 16:40 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 18:46 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:37 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 15:13 +0300
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 13:32 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 19:00 +0200
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 01:34 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-28 10:08 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-28 10:37 +0100
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-28 14:13 +0200
Re: Do you insist on const-correctness? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 13:50 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:37 +0300
Re: Do you insist on const-correctness? scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 14:46 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:23 +0200
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 11:42 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 15:27 +0300
Re: Do you insist on const-correctness? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-27 06:44 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-27 17:56 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-27 22:12 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 23:53 +0100
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:25 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 17:00 +0000
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 09:58 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 00:41 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 22:33 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 01:50 +0300
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 09:56 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-30 17:42 +0000
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 15:42 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 11:19 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-26 20:53 +0300
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-26 19:15 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-26 23:05 +0000
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 01:45 +0100
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-26 19:43 -0700
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-27 03:21 +0000
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-26 20:56 -0700
Re: Do you insist on const-correctness? Bart <bc@freeuk.com> - 2023-09-27 10:36 +0100
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-27 03:17 +0000
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-27 16:46 +0200
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-25 21:16 +0200
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 00:38 +0300
Re: Do you insist on const-correctness? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-29 10:07 -0700
Re: Do you insist on const-correctness? David Brown <david.brown@hesbynett.no> - 2023-09-30 17:34 +0200
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-23 11:57 -0700
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@gmail.moc> - 2023-09-24 00:07 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 02:38 +0000
Re: Do you insist on const-correctness? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-09-18 11:07 +0300
Re: Do you insist on const-correctness? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-18 15:24 +0000
Re: Do you insist on const-correctness? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-18 07:21 -0700
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-19 09:41 +0200 |
| Message-ID | <uebjbs$28ata$3@dont-email.me> |
| In reply to | #175946 |
On 18/09/2023 23:01, Bart wrote:
> On 18/09/2023 20:59, David Brown wrote:
>> On 18/09/2023 20:36, Bart wrote:
>>> On 18/09/2023 19:10, Kaz Kylheku wrote:
>>>> On 2023-09-18, Scott Lurndal <scott@slp53.sl.home> wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>
>>>>>> * Variables can often be declared "const". This leads to clearer
>>>>>> code
>>>>>> that is easier to reason about - things don't change, and you only
>>>>>> have
>>>>>> to look at one line to see the value that the variable has. For
>>>>>> non-const variables, you have to look throughout their lifetimes -
>>>>>> this
>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>
>>>>> I would add that declaring variables const gives the optimization pass
>>>>> additional information
>>>>
>>>> Declaring variables const provides no additional optimizing info over
>>>> just not assigning to the variable and not taking its address.
>>>>
>>>
>>> If you take a program like this:
>>>
>>> typedef struct {int d,m,y;} date;
>>>
>>> void fred(date d) {}
>>> void bill(const date d) {}
>>>
>>> int main(void) {
>>> date dd;
>>>
>>> fred(dd);
>>> bill(dd);
>>>
>>> On a modern ABI where the struct is passed internally by reference
>>> (if not, make it bigger), a compiler may be obliged to copy the
>>> struct to a temporary location when calling fred(), but doesn't need
>>> to do so when calling bill(), if it trusts that 'const' qualifier.
>>
>> The compiler can't trust the "const" qualifier. (Well, it can in this
>> case where it can see the definition of "bill" - but I assume you
>> meant when the function was defined externally.) It is legal for
>> program to cast a pointer-to-const to a pointer-to-non-const, and use
>> that to change the value, as long as the original object was not
>> defined as "const".
>
> So, basically, 'const' can never be trusted?
Not fully, no.
int foo(const int * p) {
int * q = (int *) p;
*q++;
return *q;
}
You have to go out of your way to remove the "const" qualifier, so
"const" is good at stopping accidents. And good programmers are not
going to break "const" without very good reason (and hopefully very good
documentation), but it certainly can be done.
The "const" qualifier in C is about as good as can be made for something
that was added to the language. To give a language a proper concept of
read-only access that can't be broken, I believe you really need to have
it as a fundamental from the start. (It is the norm for functional
programming languages, for examples.) "const" in C is far from perfect
in all cases, but useful in many situations nonetheless.
>
> If you have this:
>
> extern void F(void);
> const int abc=100;
>
> int main(void) {
>
> F();
> abc;
>
> Then this point, a compiler can never assume that 'abc' still has the
> value '100' at this point?
>
Ah, that's a little different. If an object is /defined/ with "const",
then changing its value is undefined behaviour. And that means the
compiler /can/ assume it does not change.
This is true even if you have code :
int * p = (int *) &abc;
*p = 123;
The compiler can still assume "abc" is 100 after that code. Maybe the
program will crash on the line "*p = 123;", due to memory protection
trapping. Maybe it will run and crash later - its undefined behaviour,
so there are no guarantees.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-19 10:12 +0100 |
| Message-ID | <uebom4$29dfb$1@dont-email.me> |
| In reply to | #176005 |
On 19/09/2023 08:41, David Brown wrote:
> On 18/09/2023 23:01, Bart wrote:
>> If you have this:
>>
>> extern void F(void);
>> const int abc=100;
>>
>> int main(void) {
>>
>> F();
>> abc;
>>
>> Then this point, a compiler can never assume that 'abc' still has the
>> value '100' at this point?
>>
>
> Ah, that's a little different. If an object is /defined/ with "const",
> then changing its value is undefined behaviour. And that means the
> compiler /can/ assume it does not change.
>
> This is true even if you have code :
>
> int * p = (int *) &abc;
> *p = 123;
>
> The compiler can still assume "abc" is 100 after that code. Maybe the
> program will crash on the line "*p = 123;", due to memory protection
> trapping. Maybe it will run and crash later - its undefined behaviour,
> so there are no guarantees.
Making 'abc' static complicates things because some compilers will put
it into read-only memory. A test program where F was in a second module
that defined 'abc' without 'const', was able to modify 'abc' using
bcc/tcc, but it crashed on gcc.
A better example would have 'abc' as a const local which is somehow
accessible to an external function.
(I've played around with 'let' in my language, which works for simple
variables. You can't assign to them again, but also you can't apply &,
and they can't be passed to a function as a by-reference argument.
I didn't like it because it doesn't work for more elaborate types (where
applying & may be essential), and such variables have to be declared at
the first point of use. Currently 'let' variable are mainly used
internally for implicitly-declared for-loop indices.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-19 17:10 +0200 |
| Message-ID | <uecdl9$2dc51$1@dont-email.me> |
| In reply to | #176012 |
On 19/09/2023 11:12, Bart wrote:
> On 19/09/2023 08:41, David Brown wrote:
>> On 18/09/2023 23:01, Bart wrote:
>
>>> If you have this:
>>>
>>> extern void F(void);
>>> const int abc=100;
>>>
>>> int main(void) {
>>>
>>> F();
>>> abc;
>>>
>>> Then this point, a compiler can never assume that 'abc' still has the
>>> value '100' at this point?
>>>
>>
>> Ah, that's a little different. If an object is /defined/ with
>> "const", then changing its value is undefined behaviour. And that
>> means the compiler /can/ assume it does not change.
>>
>> This is true even if you have code :
>>
>> int * p = (int *) &abc;
>> *p = 123;
>>
>> The compiler can still assume "abc" is 100 after that code. Maybe the
>> program will crash on the line "*p = 123;", due to memory protection
>> trapping. Maybe it will run and crash later - its undefined
>> behaviour, so there are no guarantees.
>
> Making 'abc' static complicates things because some compilers will put
> it into read-only memory.
Did you mean "making 'abc' statically allocated", or "giving 'abc'
program lifetime" here, as distinct from making it a local stack
variable? I'll assume yes, since that makes most sense to me. (The
term "static" is notoriously over-used in C.)
Yes, compilers can put such defined-as-const data into read-only memory.
I don't see how it complicates anything, however.
(Theoretically, that could be done with local non-static consts too. In
practice, it can be done if the initialiser of the const is constant at
compile-time, depending on details of what is done with its address. If
the initialiser varies when the function is run, you'd need a target
that lets you control write access to stack data - weird, but feasible,
and perhaps useful for highly secure systems.)
> A test program where F was in a second module
> that defined 'abc' without 'const', was able to modify 'abc' using
> bcc/tcc, but it crashed on gcc.
Test programs do not define C - the standards documents defined C.
The standards say that if an object is defined as "const", then any
attempt to modify it is undefined behaviour. An implementation may
allow it, or crash the program, or launch nasal daemons, according to
the day of the week. This applies equally to local const data and
file-scope const data.
>
> A better example would have 'abc' as a const local which is somehow
> accessible to an external function.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-19 22:22 +0100 |
| Message-ID | <ued3fh$2hnap$1@dont-email.me> |
| In reply to | #176033 |
On 19/09/2023 16:10, David Brown wrote:
> On 19/09/2023 11:12, Bart wrote:
>> Making 'abc' static complicates things because some compilers will put
>> it into read-only memory.
>
>
> Did you mean "making 'abc' statically allocated", or "giving 'abc'
> program lifetime" here, as distinct from making it a local stack
> variable? I'll assume yes, since that makes most sense to me. (The
> term "static" is notoriously over-used in C.)
>
> Yes, compilers can put such defined-as-const data into read-only memory.
>
> I don't see how it complicates anything, however.
>
>
> (Theoretically, that could be done with local non-static consts too. In
> practice, it can be done if the initialiser of the const is constant at
> compile-time, depending on details of what is done with its address. If
> the initialiser varies when the function is run, you'd need a target
> that lets you control write access to stack data - weird, but feasible,
> and perhaps useful for highly secure systems.)
>
>
>> A test program where F was in a second module that defined 'abc'
>> without 'const', was able to modify 'abc' using bcc/tcc, but it
>> crashed on gcc.
>
> Test programs do not define C - the standards documents defined C.
>
> The standards say that if an object is defined as "const", then any
> attempt to modify it is undefined behaviour.
Why doesn't this apply to my const struct argument?
You might say that the implementing module could look like this:
void fred(const date);
....
void fred(date d) {... modify elements of d ...}
But a module calling fred() as an external function will see only the
declaration using 'const'.
Is that not enough to persuade a compile that fred will never modify the
struct without causing UB? (I couldn't get gcc to report the
inconsistent use of 'const' above.)
If not, then what is the point of 'const' in the declaration? Because if
it's not good enough for a compiler, it won't be for a human either.
For that matter, what's the point of even this:
extern int puts(const char*);
since the actual definition might have no 'const' at all.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-19 15:35 -0700 |
| Message-ID | <87h6npiyfx.fsf@nosuchdomain.example.com> |
| In reply to | #176039 |
Bart <bc@freeuk.com> writes:
> On 19/09/2023 16:10, David Brown wrote:
[...]
>> Test programs do not define C - the standards documents defined C.
>> The standards say that if an object is defined as "const", then any
>> attempt to modify it is undefined behaviour.
>
> Why doesn't this apply to my const struct argument?
>
> You might say that the implementing module could look like this:
>
> void fred(const date);
> ....
> void fred(date d) {... modify elements of d ...}
>
> But a module calling fred() as an external function will see only the
> declaration using 'const'.
And "const" on a parameter declaration in a function declaration that's
not part of a definition is semantically meaningless.
> Is that not enough to persuade a compile that fred will never modify
> the struct without causing UB? (I couldn't get gcc to report the
> inconsistent use of 'const' above.)
A compiler may *always* assume that a function will not modify an object
that's passed as a parameter, because that's part of the semantics of
C's pass-by-value. The compiler must do whatever is necessary to ensure
correct behavior, typically by making a copy of the argument object.
(Note that the argument isn't necessarily an lvalue, so there might not
be an object to modify.)
> If not, then what is the point of 'const' in the declaration? Because
> if it's not good enough for a compiler, it won't be for a human
> either.
There is very little point in having "const" on a parameter in a
function declaration that's not part of a definition. It's ignored.
See N1570 6.7.6.3p15, which says that when determining compatibility of
function types "each parameter declared with qualified type is taken as
having the unqualified version of its declared type".
Similarly, but due to a different rule, this declaration, even if it's
part of a definition:
void foo(char array[42]);
is equivalent to:
void foo(char *array);
and the 42 is ignored.
(No doubt you think this is a flaw in the language. I don't necessarily
disagree, but I'm not interested in getting into that. I'm describing
the language as it's actually specified.)
> For that matter, what's the point of even this:
>
> extern int puts(const char*);
>
> since the actual definition might have no 'const' at all.
That's very different. That const applies, not to the parameter object,
but to what it points to.
If the "const" were not there:
extern int puts(char*);
then this:
const char *s = "hello";
puts(s);
would be a constraint violation.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-19 22:44 +0000 |
| Message-ID | <20230919152101.428@kylheku.com> |
| In reply to | #176039 |
On 2023-09-19, Bart <bc@freeuk.com> wrote:
>> The standards say that if an object is defined as "const", then any
>> attempt to modify it is undefined behaviour.
>
> Why doesn't this apply to my const struct argument?
It does; if a function definition's argument is a const struct,
then that may not be modified. Assigning to it is a constraint
violation, and underhanded modification is UB.
The const can be removed without changing the function's type,
updating its declaration or recompiling any callers.
It's entirely a private matter, encapsulated in the function.
> You might say that the implementing module could look like this:
>
> void fred(const date);
> ....
> void fred(date d) {... modify elements of d ...}
>
> But a module calling fred() as an external function will see only the
> declaration using 'const'.
>
> Is that not enough to persuade a compile that fred will never modify the
> struct without causing UB? (I couldn't get gcc to report the
> inconsistent use of 'const' above.)
This is enough to convince to indicate that the function doesn't modify
the caller's structure without causing UB:
void fred(date);
The ISO C standard makes it clear that qualifiers on the function
parameters in a declaration are ignored; they persuade of nothing.
> If not, then what is the point of 'const' in the declaration? Because if
The point of const in a declaration is to allow verbatim copy and paste of
the declaration from the definition: to obtain a valid declaration from
a valid definition by dropping the { ... } body, replacing it with
a semicolon. That's it.
I would say, it's a poor coding style if written by hand.
It could help with generated code, e.g. by macros.
#define PARAMS (const int x, char *p)
void foo PARAMS; // decl
void foo PARAMS // def
{
}
A text processing tool which scans .c files to generate .h files is
easier to write if it doesn't have to parse parameter lists in
order to remove qualifiers on parameters.
One such tool is the "makeheaders" program written in 1993 by the
SQLite author, and included in the Fossil version control system.
It is hosted here: https://fossil-scm.org/home/file?name=tools/makeheaders.c
I have this:
$ cat qual.c
int x(const int y)
{
return y
}
I run this:
$ ./makeheaders qual.c
Now qual.h has this:
$ cat qual.h
/* This file was automatically generated. Do not edit! */
#undef INTERFACE
int x(const int y);
As you can see, it just copied the declaration verbatim, const and all.
That guy obviously has an opinion: header files in C are a silly convention
and in many cases duplicate material from base source files. Many languages
work fine without header files. Why not automate it.
>baes it's not good enough for a compiler, it won't be for a human either.
>
> For that matter, what's the point of even this:
>
> extern int puts(const char*);
>
> since the actual definition might have no 'const' at all.
No, that const is not on the parameter itself; it's part of the type the
parameter points to. That const isn't optional in the definition.
int f(const char *) is not compatible with int f(char *).
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-20 12:55 +0200 |
| Message-ID | <ueej2i$2t7k6$1@dont-email.me> |
| In reply to | #176039 |
On 19/09/2023 23:22, Bart wrote:
> On 19/09/2023 16:10, David Brown wrote:
>> On 19/09/2023 11:12, Bart wrote:
>
>>> Making 'abc' static complicates things because some compilers will
>>> put it into read-only memory.
>>
>>
>> Did you mean "making 'abc' statically allocated", or "giving 'abc'
>> program lifetime" here, as distinct from making it a local stack
>> variable? I'll assume yes, since that makes most sense to me. (The
>> term "static" is notoriously over-used in C.)
>>
>> Yes, compilers can put such defined-as-const data into read-only memory.
>>
>> I don't see how it complicates anything, however.
>>
>>
>> (Theoretically, that could be done with local non-static consts too.
>> In practice, it can be done if the initialiser of the const is
>> constant at compile-time, depending on details of what is done with
>> its address. If the initialiser varies when the function is run,
>> you'd need a target that lets you control write access to stack data -
>> weird, but feasible, and perhaps useful for highly secure systems.)
>>
>>
>>> A test program where F was in a second module that defined 'abc'
>>> without 'const', was able to modify 'abc' using bcc/tcc, but it
>>> crashed on gcc.
>>
>> Test programs do not define C - the standards documents defined C.
>>
>> The standards say that if an object is defined as "const", then any
>> attempt to modify it is undefined behaviour.
>
> Why doesn't this apply to my const struct argument?
Think about how function calls actually happen. Consider this possible
code :
// Part of "fred.c", separately compiled
void fred(date x)
{
... do something with x ...
}
// Part of "foo.c", separately compiled
extern void fred(const date y);
void foo(void) {
const date dd = { 1, 2, 3 };
fred(dd);
... do something more with dd ...
}
You can think of parameter passing and function calling as being roughly
like this transform :
void foo(void) {
const date dd = { 1, 2, 3 };
// Call to fred(dd), with void fred(const date y)
{
// Assign the parameters, done within "foo"
const date y = dd;
// The function itself, defined void fred(date x)
date x = y;
{
// The body of fred()
... do something with x ...
}
}
... do something more with dd ...
}
The actual creation of the "virtual local variables", if I may call them
that, is done within the context of the caller - but they are used
within the called function. Compilers would not have to make two sets
of virtual local variables - only one set must be made. But the C
standards describe the conversions as being "the arguments are
implicitly converted, as if by assignment".
Note that here I have, just for fun, declared "fred" with a non-const
parameter and defined it with a const parameter. This is fine in C -
the qualifiers are ignored when considering the compatibility of
function signatures and when setting the parameters.
So inside "fred", the function can change the parameter "x". It can do
that even though the declaration that "foo" saw was for a "const"
parameter. As parameter passing is done semantically as though by
assignment, that's fine - it's using its own local copy, independent of
the original "dd" in the calling function. This is the case even if the
parameter is passed on the stack rather than in registers. But it means
that "foo" has to make a copy of "dd" to pass to the function - it can't
pass a pointer to the original "dd" and hope the called function does
not change it.
To be clear - I'd be happier if parameter qualifiers /were/ required to
match in all declarations and definitions of a function. I'd be happier
if modifying a "const" parameter in function was undefined behaviour,
even if you used "loopholes" via pointer casts. That would allow some
additional optimisations, such as avoiding extra copies in some
situations, and would be more consistent IMHO.
>
> You might say that the implementing module could look like this:
>
> void fred(const date);
> ....
> void fred(date d) {... modify elements of d ...}
>
> But a module calling fred() as an external function will see only the
> declaration using 'const'.
>
Yes.
> Is that not enough to persuade a compile that fred will never modify the
> struct without causing UB? (I couldn't get gcc to report the
> inconsistent use of 'const' above.)
No, sorry.
>
> If not, then what is the point of 'const' in the declaration? Because if
> it's not good enough for a compiler, it won't be for a human either.
There is no point in having "const" (or "volatile") qualifiers on
parameters. (You can usefully - often very usefully - have qualifiers
on pointed-to types. "int * const p" is pointless for a parameter in a
declaration, but "const int * p" is entirely different.)
You can, if you like, put a "const" qualifier on a parameter in a
function definition - it will stop you accidentally changing it in the
function body.
>
> For that matter, what's the point of even this:
>
> extern int puts(const char*);
>
> since the actual definition might have no 'const' at all.
>
Pointed-to types are a different matter entirely. "const char *" and
"char *" have very different semantics, and are not compatible parameter
types.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-18 14:07 -0700 |
| Message-ID | <87a5tjkx66.fsf@nosuchdomain.example.com> |
| In reply to | #175935 |
Bart <bc@freeuk.com> writes:
> On 18/09/2023 19:10, Kaz Kylheku wrote:
>> On 2023-09-18, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>
>>>> * Variables can often be declared "const". This leads to clearer code
>>>> that is easier to reason about - things don't change, and you only have
>>>> to look at one line to see the value that the variable has. For
>>>> non-const variables, you have to look throughout their lifetimes - this
>>>> is maximally bad if they are defined at the top of the function.
>>>
>>> I would add that declaring variables const gives the optimization pass
>>> additional information
>> Declaring variables const provides no additional optimizing info
>> over
>> just not assigning to the variable and not taking its address.
>>
>
> If you take a program like this:
>
> typedef struct {int d,m,y;} date;
>
> void fred(date d) {}
> void bill(const date d) {}
>
> int main(void) {
> date dd;
>
> fred(dd);
> bill(dd);
>
> On a modern ABI where the struct is passed internally by reference (if
> not, make it bigger), a compiler may be obliged to copy the struct to
> a temporary location when calling fred(), but doesn't need to do so
> when calling bill(), if it trusts that 'const' qualifier.
[...]
Interesting point, but I doubt that any compilers do this.
The compiler can assume the parameter object is not modified
only if the *definition* is visible, as it is in your example.
A standalone declaration with "const" on a parameter gives no
information about whether the parameter is const in the definition.
And a compiler could inline the call to bill(), particularly if
there's only one call. Once it's inlined, the compiler can see
whether d is actually modified. (Multiple calls and/or external
visibility make inlining more difficult.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-09-19 00:13 -0400 |
| Message-ID | <ueb75c$2667l$1@dont-email.me> |
| In reply to | #175935 |
On 18/09/2023 20:36, Bart wrote:
...
> typedef struct {int d,m,y;} date;
>
> void fred(date d) {}
> void bill(const date d) {}
In a declaration that's not a definition:
void bill(const date d);
qualifiers such as "const" that are applied directly to parameters are
simply ignored. In the declaration which is part of a definition of the
function, such qualifiers matter only inside the function - they have no
effect on compatibility between the function's definition and it's other
declarations.
The only reason to declare such a parameter "const" is if it's not
supposed to be changed. In that regard, it's just like any other
variable which is local to the function. It's a good general rule that
you should declare any variable "const" if you know that it should never
be changed from the value it's initialized with. If that's the case, the
qualifier ensures that most code which puts the variable at risk of
being changed will make it mandatory for the compiler to issue a
diagnostic. When you see that diagnostic, you know that either you were
wrong about that variable never changing, or the code that triggered the
diagnostic needs to be corrected.
You don't need the "const" to enable any applicable optimizations - if
your code does not, in fact, change the variable, the compiler can
easily detect that fact and apply any optimizations enabled by that fact.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-19 09:57 +0100 |
| Message-ID | <uebnp5$2985i$1@dont-email.me> |
| In reply to | #175989 |
On 19/09/2023 05:13, James Kuyper wrote:
> On 18/09/2023 20:36, Bart wrote:
> ...
>> typedef struct {int d,m,y;} date;
>>
>> void fred(date d) {}
>> void bill(const date d) {}
>
> In a declaration that's not a definition:
>
> void bill(const date d);
>
> qualifiers such as "const" that are applied directly to parameters are
> simply ignored. In the declaration which is part of a definition of the
> function, such qualifiers matter only inside the function - they have no
> effect on compatibility between the function's definition and it's other
> declarations.
>
> The only reason to declare such a parameter "const" is if it's not
> supposed to be changed.
Structs passed 'by-value' on a modern ABI can very possibly be passed
by-reference. It depends on the struct details and ABI.
This makes it quite different from other kinds of objects which really
are passed by value. (An array object is another which is implicitly
passed by reference, but that detail is exposed in the language and
people will aware of it.)
> In that regard, it's just like any other
> variable which is local to the function. It's a good general rule that
> you should declare any variable "const" if you know that it should never
> be changed from the value it's initialized with. If that's the case, the
> qualifier ensures that most code which puts the variable at risk of
> being changed will make it mandatory for the compiler to issue a
> diagnostic. When you see that diagnostic, you know that either you were
> wrong about that variable never changing, or the code that triggered the
> diagnostic needs to be corrected.
>
> You don't need the "const" to enable any applicable optimizations - if
> your code does not, in fact, change the variable, the compiler can
> easily detect that fact and apply any optimizations enabled by that fact.
With independent compilation, or using external libraries, in general
the bodies of any functions that are called will not be visible, only
the declarations.
So that sort of analysis cannot be applied.
Apparently, to guaranteed pass-by-value semantics even though 'const'
has been applied, it is necessary to create a copy of such structs and
pass that instead.
But look at this example function of a library (Raylib) which uses
by-value structs extensively:
RLAPI Vector2 GetWorldToScreen(Vector3 position, Camera camera);
extern Vector3 arg1;
extern Camera arg2;
int main(void) {
GetWorldToScreen(arg1, arg2);
}
(Full specs are given below.)
The Vector3 type is 12 bytes, and Camera is 44 bytes. 56 bytes that need
copying on every call. This API has 100s of such functions, and structs
are always passed by value.
Wouldn't it be better if that copy could be avoided? That is, without
rewriting the library to use explicit references, and having to use &
for each passed struct. (I think that would also rule out being able to
use compound literals.)
Avoiding the copy means less generated code, and faster execution,
although the overheads for this library are not critical.
----------------------------------
#define RLAPI
typedef struct Vector2 {
float x; // Vector x component
float y; // Vector y component
} Vector2;
typedef struct Vector3 {
float x; // Vector x component
float y; // Vector y component
float z; // Vector z component
} Vector3;
typedef struct Camera3D {
Vector3 position; // Camera position
Vector3 target; // Camera target it looks-at
Vector3 up; // Camera up vector (rotation over its axis)
float fovy; // Camera field-of-view aperture in Y
(degrees) in perspective, used as near plane width in orthographic
int projection; // Camera projection: CAMERA_PERSPECTIVE or
CAMERA_ORTHOGRAPHIC
} Camera3D;
typedef Camera3D Camera; // Camera type fallback, defaults to Camera3D
RLAPI Vector2 GetWorldToScreen(Vector3 position, Camera camera);
extern Vector3 arg1;
extern Camera arg2;
int main(void) {
GetWorldToScreen(arg1, arg2);
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-19 16:37 +0200 |
| Message-ID | <uecbn0$2cvjt$1@dont-email.me> |
| In reply to | #176010 |
On 19/09/2023 10:57, Bart wrote:
> On 19/09/2023 05:13, James Kuyper wrote:
>> On 18/09/2023 20:36, Bart wrote:
>> ...
>>> typedef struct {int d,m,y;} date;
>>>
>>> void fred(date d) {}
>>> void bill(const date d) {}
>>
>> In a declaration that's not a definition:
>>
>> void bill(const date d);
>>
>> qualifiers such as "const" that are applied directly to parameters are
>> simply ignored. In the declaration which is part of a definition of the
>> function, such qualifiers matter only inside the function - they have no
>> effect on compatibility between the function's definition and it's other
>> declarations.
>>
>> The only reason to declare such a parameter "const" is if it's not
>> supposed to be changed.
>
> Structs passed 'by-value' on a modern ABI can very possibly be passed
> by-reference. It depends on the struct details and ABI.
Yes, but that is invisible to C.
>
> This makes it quite different from other kinds of objects which really
> are passed by value. (An array object is another which is implicitly
> passed by reference, but that detail is exposed in the language and
> people will aware of it.)
No. C is defined in terms of an abstract machine (plus a few specific
implementation-defined behaviours), not by how a particular
implementation might choose to pass objects around. Logically, you have
pass by value - /not/ pass by reference. (Even when you have pointers,
you are passing the pointer by value.) So the implementation has to
give the same effects regardless of how it actually implements the
pass-by-value for structs.
>
>
>> In that regard, it's just like any other
>> variable which is local to the function. It's a good general rule that
>> you should declare any variable "const" if you know that it should never
>> be changed from the value it's initialized with. If that's the case, the
>> qualifier ensures that most code which puts the variable at risk of
>> being changed will make it mandatory for the compiler to issue a
>> diagnostic. When you see that diagnostic, you know that either you were
>> wrong about that variable never changing, or the code that triggered the
>> diagnostic needs to be corrected.
>>
>> You don't need the "const" to enable any applicable optimizations - if
>> your code does not, in fact, change the variable, the compiler can
>> easily detect that fact and apply any optimizations enabled by that fact.
>
> With independent compilation, or using external libraries, in general
> the bodies of any functions that are called will not be visible, only
> the declarations.
Yes.
>
> So that sort of analysis cannot be applied.
Yes.
>
> Apparently, to guaranteed pass-by-value semantics even though 'const'
> has been applied, it is necessary to create a copy of such structs and
> pass that instead.
Yes.
>
> But look at this example function of a library (Raylib) which uses
> by-value structs extensively:
>
> RLAPI Vector2 GetWorldToScreen(Vector3 position, Camera camera);
>
> extern Vector3 arg1;
> extern Camera arg2;
>
> int main(void) {
> GetWorldToScreen(arg1, arg2);
> }
>
> (Full specs are given below.)
>
> The Vector3 type is 12 bytes, and Camera is 44 bytes. 56 bytes that need
> copying on every call. This API has 100s of such functions, and structs
> are always passed by value.
If that's the way they have designed the API, that's how it works.
>
> Wouldn't it be better if that copy could be avoided? That is, without
> rewriting the library to use explicit references, and having to use &
> for each passed struct. (I think that would also rule out being able to
> use compound literals.)
You can certainly argue that alternatives would be better. Maybe the
calculations and run-time of the functions make the overhead here
insignificant - I don't know the library.
>
> Avoiding the copy means less generated code, and faster execution,
> although the overheads for this library are not critical.
>
Perhaps there are historic reasons - maybe "Camera" used to be quite
small. Maybe the developers feel passing the structs by value is
clearer and it is easier to see what the code is doing, and to avoid
errors, and this is worth the extra overhead. Maybe the developers work
mainly with C++, where you would be likely to use a const reference in
such cases (thus passing a pointer), and translated it directly to C.
You'd have to ask the library developers.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-19 16:55 +0000 |
| Message-ID | <20230919095438.235@kylheku.com> |
| In reply to | #176030 |
On 2023-09-19, David Brown <david.brown@hesbynett.no> wrote: > On 19/09/2023 10:57, Bart wrote: >> Structs passed 'by-value' on a modern ABI can very possibly be passed >> by-reference. It depends on the struct details and ABI. > > Yes, but that is invisible to C. Nope! Even passing on the stack is by reference, because there is a stack pointer which is a reference. Lalala, plugging my ears.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-19 15:16 -0700 |
| Message-ID | <ued6jh$2i57e$2@dont-email.me> |
| In reply to | #176034 |
On 9/19/2023 9:55 AM, Kaz Kylheku wrote: > On 2023-09-19, David Brown <david.brown@hesbynett.no> wrote: >> On 19/09/2023 10:57, Bart wrote: >>> Structs passed 'by-value' on a modern ABI can very possibly be passed >>> by-reference. It depends on the struct details and ABI. >> >> Yes, but that is invisible to C. > > Nope! Even passing on the stack is by reference, because there is > a stack pointer which is a reference. Lalala, plugging my ears. Using a node contained on the stack of a thread that wants to wait via futex. Well, the node, residing on the stack or per-thread memory, can be linked into a wait queue. ;^)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-18 20:31 +0200 |
| Message-ID | <uea52i$1stu4$2@dont-email.me> |
| In reply to | #175913 |
On 18/09/2023 17:54, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 18/09/2023 10:53, Anton Shepelev wrote: > >> * Variables can often be declared "const". This leads to clearer code >> that is easier to reason about - things don't change, and you only have >> to look at one line to see the value that the variable has. For >> non-const variables, you have to look throughout their lifetimes - this >> is maximally bad if they are defined at the top of the function. > > I would add that declaring variables const gives the optimization pass > additional information and may result in more efficient register > allocation and code generation. > > const uint32_t regnum = bit::extract(instruction, 4, 0); > > also enhances readability. I agree that adding "const" improves readability, because it tells the human reader that the thing never changes. But it doesn't help the compiler, since the compiler can read the rest of the function and see that it does not change. (So could a human reader, but I care about saving the human reader the effort of having to do that - I don't care about saving the compiler effort!)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-18 14:03 -0700 |
| Message-ID | <ueadvt$1uk16$4@dont-email.me> |
| In reply to | #175933 |
On 9/18/2023 11:31 AM, David Brown wrote:
> On 18/09/2023 17:54, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>
>>> * Variables can often be declared "const". This leads to clearer code
>>> that is easier to reason about - things don't change, and you only have
>>> to look at one line to see the value that the variable has. For
>>> non-const variables, you have to look throughout their lifetimes - this
>>> is maximally bad if they are defined at the top of the function.
>>
>> I would add that declaring variables const gives the optimization pass
>> additional information and may result in more efficient register
>> allocation and code generation.
>>
>> const uint32_t regnum = bit::extract(instruction, 4, 0);
>>
>> also enhances readability.
>
> I agree that adding "const" improves readability, because it tells the
> human reader that the thing never changes.
>
> But it doesn't help the compiler, since the compiler can read the rest
> of the function and see that it does not change. (So could a human
> reader, but I care about saving the human reader the effort of having to
> do that - I don't care about saving the compiler effort!)
>
>
const as in:
void
ct_foo(
ct_foobar* const self
){
// self cannot be changed... So be it!
}
Kosher? ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-18 14:04 -0700 |
| Message-ID | <ueae1i$1uk16$5@dont-email.me> |
| In reply to | #175947 |
On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
> On 9/18/2023 11:31 AM, David Brown wrote:
>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>
>>>> * Variables can often be declared "const". This leads to clearer code
>>>> that is easier to reason about - things don't change, and you only have
>>>> to look at one line to see the value that the variable has. For
>>>> non-const variables, you have to look throughout their lifetimes - this
>>>> is maximally bad if they are defined at the top of the function.
>>>
>>> I would add that declaring variables const gives the optimization pass
>>> additional information and may result in more efficient register
>>> allocation and code generation.
>>>
>>> const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>
>>> also enhances readability.
>>
>> I agree that adding "const" improves readability, because it tells the
>> human reader that the thing never changes.
>>
>> But it doesn't help the compiler, since the compiler can read the rest
>> of the function and see that it does not change. (So could a human
>> reader, but I care about saving the human reader the effort of having
>> to do that - I don't care about saving the compiler effort!)
>>
>>
>
> const as in:
>
> void
> ct_foo(
> ct_foobar* const self
> ){
> // self cannot be changed... So be it!
> }
>
> Kosher? ;^)
What about:
void
ct_foo(
ct_foobar const* const self
){
// self cannot be changed... So be it!
// the ct_foobar that self points to is const...
}
:^)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-18 22:26 +0100 |
| Message-ID | <87jzsni350.fsf@bsb.me.uk> |
| In reply to | #175948 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
>> On 9/18/2023 11:31 AM, David Brown wrote:
>>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>
>>>>> * Variables can often be declared "const". This leads to clearer code
>>>>> that is easier to reason about - things don't change, and you only have
>>>>> to look at one line to see the value that the variable has. For
>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>> is maximally bad if they are defined at the top of the function.
>>>>
>>>> I would add that declaring variables const gives the optimization pass
>>>> additional information and may result in more efficient register
>>>> allocation and code generation.
>>>>
>>>> const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>>
>>>> also enhances readability.
>>>
>>> I agree that adding "const" improves readability, because it tells the
>>> human reader that the thing never changes.
>>>
>>> But it doesn't help the compiler, since the compiler can read the rest
>>> of the function and see that it does not change. (So could a human
>>> reader, but I care about saving the human reader the effort of having to
>>> do that - I don't care about saving the compiler effort!)
>>>
>>>
>> const as in:
>> void
>> ct_foo(
>> ct_foobar* const self
>> ){
>> // self cannot be changed... So be it!
>> }
>> Kosher? ;^)
...cannot be changed without undefined behaviour.
> What about:
>
> void
> ct_foo(
> ct_foobar const* const self
> ){
> // self cannot be changed... So be it!
> // the ct_foobar that self points to is const...
> }
Technically, no. The ct_foobar that self points to can't be changed
using the self pointer directly, but the ct_foobar object itself might
be const or it might not be, and it might even be able to be changed by
the function in question:
void ct_eg(const ct_foobar *self, ct_foobar *other_foobar)
{
...
change_this_thing_beyond_recognition(other_foobar);
...
}
and later...
ct_foobar my_obj;
...
ct_eg(&my_obj, &my_obj);
This is (in part) what restrict-qualified pointers are for.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-18 15:59 -0700 |
| Message-ID | <ueakp8$1vvcp$1@dont-email.me> |
| In reply to | #175952 |
On 9/18/2023 2:26 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
>>> On 9/18/2023 11:31 AM, David Brown wrote:
>>>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>
>>>>>> * Variables can often be declared "const". This leads to clearer code
>>>>>> that is easier to reason about - things don't change, and you only have
>>>>>> to look at one line to see the value that the variable has. For
>>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>
>>>>> I would add that declaring variables const gives the optimization pass
>>>>> additional information and may result in more efficient register
>>>>> allocation and code generation.
>>>>>
>>>>> const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>>>
>>>>> also enhances readability.
>>>>
>>>> I agree that adding "const" improves readability, because it tells the
>>>> human reader that the thing never changes.
>>>>
>>>> But it doesn't help the compiler, since the compiler can read the rest
>>>> of the function and see that it does not change. (So could a human
>>>> reader, but I care about saving the human reader the effort of having to
>>>> do that - I don't care about saving the compiler effort!)
>>>>
>>>>
>>> const as in:
>>> void
>>> ct_foo(
>>> ct_foobar* const self
>>> ){
>>> // self cannot be changed... So be it!
>>> }
>>> Kosher? ;^)
>
> ...cannot be changed without undefined behaviour.
>
>> What about:
>>
>> void
>> ct_foo(
>> ct_foobar const* const self
>> ){
>> // self cannot be changed... So be it!
>> // the ct_foobar that self points to is const...
>> }
>
> Technically, no.
When I read right to left wrt:
ct_foobar const* const self
I see,
self is a:
const pointer to a
const ct_foobar
Did I get it wrong?
The ct_foobar that self points to can't be changed
> using the self pointer directly, but the ct_foobar object itself might
> be const or it might not be, and it might even be able to be changed by
> the function in question:
>
> void ct_eg(const ct_foobar *self, ct_foobar *other_foobar)
> {
> ...
> change_this_thing_beyond_recognition(other_foobar);
> ...
> }
>
> and later...
>
> ct_foobar my_obj;
> ...
> ct_eg(&my_obj, &my_obj);
>
> This is (in part) what restrict-qualified pointers are for.
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-19 00:37 +0100 |
| Message-ID | <87edivhx3z.fsf@bsb.me.uk> |
| In reply to | #175964 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 9/18/2023 2:26 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
>>>> On 9/18/2023 11:31 AM, David Brown wrote:
>>>>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>>
>>>>>>> * Variables can often be declared "const". This leads to clearer code
>>>>>>> that is easier to reason about - things don't change, and you only have
>>>>>>> to look at one line to see the value that the variable has. For
>>>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>>
>>>>>> I would add that declaring variables const gives the optimization pass
>>>>>> additional information and may result in more efficient register
>>>>>> allocation and code generation.
>>>>>>
>>>>>> const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>>>>
>>>>>> also enhances readability.
>>>>>
>>>>> I agree that adding "const" improves readability, because it tells the
>>>>> human reader that the thing never changes.
>>>>>
>>>>> But it doesn't help the compiler, since the compiler can read the rest
>>>>> of the function and see that it does not change. (So could a human
>>>>> reader, but I care about saving the human reader the effort of having to
>>>>> do that - I don't care about saving the compiler effort!)
>>>>>
>>>>>
>>>> const as in:
>>>> void
>>>> ct_foo(
>>>> ct_foobar* const self
>>>> ){
>>>> // self cannot be changed... So be it!
>>>> }
>>>> Kosher? ;^)
>> ...cannot be changed without undefined behaviour.
>>
>>> What about:
>>>
>>> void
>>> ct_foo(
>>> ct_foobar const* const self
>>> ){
>>> // self cannot be changed... So be it!
>>> // the ct_foobar that self points to is const...
>>> }
>> Technically, no.
>
> When I read right to left wrt:
>
> ct_foobar const* const self
>
> I see,
>
> self is a:
>
> const pointer to a
>
> const ct_foobar
>
> Did I get it wrong?
No, that's a reasonable way to read the type, but that type does not
conflict with anything I said. We say "points to a const ct_foobar" but
that's a shorthand. The thing pointed to may not be const. What is
const in the pointer target type, so the lvalue expression
*self
has a const qualified type. The object pointed to can't be altered
using that lvalue expression even though the object may not itself have
a const-qualified type.
>> The ct_foobar that self points to can't be changed
>> using the self pointer directly, but the ct_foobar object itself might
>> be const or it might not be, and it might even be able to be changed by
>> the function in question:
>> void ct_eg(const ct_foobar *self, ct_foobar *other_foobar)
>> {
>> ...
>> change_this_thing_beyond_recognition(other_foobar);
>> ...
>> }
>> and later...
>> ct_foobar my_obj;
>> ...
>> ct_eg(&my_obj, &my_obj);
>> This is (in part) what restrict-qualified pointers are for.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-19 12:26 -0700 |
| Message-ID | <uecslb$2g3hn$6@dont-email.me> |
| In reply to | #175968 |
On 9/18/2023 4:37 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 9/18/2023 2:26 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 9/18/2023 2:03 PM, Chris M. Thomasson wrote:
>>>>> On 9/18/2023 11:31 AM, David Brown wrote:
>>>>>> On 18/09/2023 17:54, Scott Lurndal wrote:
>>>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>>>> On 18/09/2023 10:53, Anton Shepelev wrote:
>>>>>>>
>>>>>>>> * Variables can often be declared "const". This leads to clearer code
>>>>>>>> that is easier to reason about - things don't change, and you only have
>>>>>>>> to look at one line to see the value that the variable has. For
>>>>>>>> non-const variables, you have to look throughout their lifetimes - this
>>>>>>>> is maximally bad if they are defined at the top of the function.
>>>>>>>
>>>>>>> I would add that declaring variables const gives the optimization pass
>>>>>>> additional information and may result in more efficient register
>>>>>>> allocation and code generation.
>>>>>>>
>>>>>>> const uint32_t regnum = bit::extract(instruction, 4, 0);
>>>>>>>
>>>>>>> also enhances readability.
>>>>>>
>>>>>> I agree that adding "const" improves readability, because it tells the
>>>>>> human reader that the thing never changes.
>>>>>>
>>>>>> But it doesn't help the compiler, since the compiler can read the rest
>>>>>> of the function and see that it does not change. (So could a human
>>>>>> reader, but I care about saving the human reader the effort of having to
>>>>>> do that - I don't care about saving the compiler effort!)
>>>>>>
>>>>>>
>>>>> const as in:
>>>>> void
>>>>> ct_foo(
>>>>> ct_foobar* const self
>>>>> ){
>>>>> // self cannot be changed... So be it!
>>>>> }
>>>>> Kosher? ;^)
>>> ...cannot be changed without undefined behaviour.
>>>
>>>> What about:
>>>>
>>>> void
>>>> ct_foo(
>>>> ct_foobar const* const self
>>>> ){
>>>> // self cannot be changed... So be it!
>>>> // the ct_foobar that self points to is const...
>>>> }
>>> Technically, no.
>>
>> When I read right to left wrt:
>>
>> ct_foobar const* const self
>>
>> I see,
>>
>> self is a:
>>
>> const pointer to a
>>
>> const ct_foobar
>>
>> Did I get it wrong?
>
> No, that's a reasonable way to read the type, but that type does not
> conflict with anything I said. We say "points to a const ct_foobar" but
> that's a shorthand. The thing pointed to may not be const. What is
> const in the pointer target type, so the lvalue expression
The const is here as a hint to the compiler and an important part of the
contract for the programmer to strive to uphold. Please do not modify
self, or the const ct_foobar it points to. Fair enough? The programmer
can say, screw that, I am going to cast away the const and do some
things... Well, then missiles get launched at some rather interesting
targets. ;^o
>
> *self
>
> has a const qualified type. The object pointed to can't be altered
> using that lvalue expression even though the object may not itself have
> a const-qualified type.
>
>>> The ct_foobar that self points to can't be changed
>>> using the self pointer directly, but the ct_foobar object itself might
>>> be const or it might not be, and it might even be able to be changed by
>>> the function in question:
>>> void ct_eg(const ct_foobar *self, ct_foobar *other_foobar)
>>> {
>>> ...
>>> change_this_thing_beyond_recognition(other_foobar);
>>> ...
>>> }
>>> and later...
>>> ct_foobar my_obj;
>>> ...
>>> ct_eg(&my_obj, &my_obj);
>>> This is (in part) what restrict-qualified pointers are for.
Yup.
>
>
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web