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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-18 16:55 +0200 |
| Message-ID | <ue9ocg$1qfvq$1@dont-email.me> |
| In reply to | #175882 |
On 18/09/2023 10:53, Anton Shepelev wrote:
> Tim Rentsch to Anton Shepelev:
>
> [an unused variable removed from quoted code:]
>>> void* a_setlen( void * a, unsigned len )
>>> { struct meta_t *m ;
>>>
>>> m = META ( a );
>>> m = setlen( m, len );
>>> if( m != NULL ) a = DATA( m );
>>> else a = NULL ;
>>> return a;
>>> }
>>
>> Is there some reason not to write a shorter and simpler
>> function, such as the function below (please ignore
>> differences in layout style)
>>
>> void*
>> a_setlen( void *a, unsigned n ){
>> struct meta_t *const m = setlen( META( a ), n );
>>
>> return m ? DATA( m ) : NULL;
>> }
>
> My personal reasons are the following:
>
> 1. I prefer not to mix variable declaration and
> initialisation, but first to declare my data and then
> to work with it.
Why? I've seen people give good reasons for this habit, and bad reasons
for it, so I'm curious as to /your/ reasons!
I prefer not to declare any variable until I have a proper
initialisation for it. This gives me several advantages :
* As soon as the variable exists, it is valid - there is never a point
at which code can refer to it without it having a proper value.
* 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.
* Code is easier to write and maintain, and can more easily be re-used,
copied or re-arranged as you only have the one line (definition and
initialisation) to handle, rather than two separate lines in different
parts of the function. "Leftovers", such as your "newcap" variable in
your initial post, are much rarer.
* Making new local variables becomes "cheaper" in terms of writing the
code, and for people reading and understanding the code. This makes it
natural to write a lot of code in "static single assignment form" - you
write your code as a series of expressions, the results of which are
assigned to const variables and are therefore unchanged within their
lifetimes. This ties in very well with your points 2 and 3 below.
I am mathematically trained, and learned a lot of programming principles
using functional programming (though I am decades out of practice at
it). I have never been entirely comfortable with the idea of changing a
variable - "x = x + 1" reads as mathematical nonsense. Obviously in an
imperative language like C, you are going to update variables in loops,
but it is, to me, often better to use new const variables than to re-use
an existing variable. There's a reason why many modern programming
languages make data effectively "const" by default.
>
> 2. I consider nested calls a bit less readable than
> sequential, alghough I do not alwasy avoid them.
Agreed - with the same caveat.
>
> 3. Sequential calls let me insert ad-hoc debugging code
> at the right points, e.g. between the invocations of
> META() and setlen() above.
Agreed, and for similar reasons (and also with the same caveat).
Creating variables for each such line is even better for debugging,
especially when you temporarily add "volatile" to the declaration. Then
you can easily view the value, regardless of the optimisation, and it
also makes it simple to enforce that the order of the expression
statements in the source code and object code match (while still keeping
useful optimisation), which helps for single-stepping during debugging.
>
> 4. I consider the ternary operator a redundant special
> case of the `if' statement that increases expression
> nesting to the (granted, often but slight) detriment
> of readability.
>
I am not a big user of the ternary operator, but sometimes it makes code
clearer.
However, your layout for "if" statements is, IMHO, appalling.
(Everything here is very much IMHO.) Anyone who sent in code like that
for a code review here would be sent back again - I would not even
bother telling them why, as I would expect every C programmer (in my
field at least) to have braces in any conditional with an "else". I
would also expect far better use of white space (though I realise that
is much more personal style) :
void * setlen(void * a, unsigned int len)
{
meta_t * m1 = META(a);
meta_t * m2 = setlen(m1, len);
if (m2) {
return DATA(m);
} else {
return NULL;
}
}
I (almost) always typedef my structs - there's no benefit in my code to
writing out "struct" on each use. A struct type is a type, and writing
"struct" (or "union", or "enum") when using such types is a distraction
from the useful code.
I'd use better names for "m1" and "m2" if I knew what the code was doing
:-) And I would not consider using macros for the "META" and "DATA" -
inline functions are a far better choice here.
Occasionally I find it helpful to have a "return variable" - typically
if there is some kind of epilogue or clean-up after the return value is
calculated. Normally, however, when I have the value to return, I
prefer to return it.
Feel free to value or ignore these opinions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-18 15:54 +0000 |
| Message-ID | <4p_NM.30205$oX8.25901@fx46.iad> |
| In reply to | #175909 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-18 18:10 +0000 |
| Message-ID | <20230918110915.139@kylheku.com> |
| In reply to | #175913 |
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. -- 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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-18 19:36 +0100 |
| Message-ID | <uea5bd$1t2iu$1@dont-email.me> |
| In reply to | #175931 |
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.
This is to avoid changes made to 'd' inside the caller from affecting
the caller's data.
Although this is nothing really to do with optimisation, just common sense.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-18 19:55 +0000 |
| Message-ID | <20230918125058.653@kylheku.com> |
| In reply to | #175935 |
On 2023-09-18, Bart <bc@freeuk.com> 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) {}
The const here makes no difference.
Since this is a definition, the compiler can inline the function, and
make it disappear, since it does nothing.
> 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.
Suppose that bill is an external function, which is declared like
this:
void bill(const date d);
that const means nothing and can (really, should) be ignored.
The function definition can look like:
void bill(date d) { /*...*/ }
or like:
void bill(const date d) { /*...*/ }
both of these are correct, and their ABI must be exactly the same.
> Although this is nothing really to do with optimisation, just common sense.
Common sense is no substitute for 1) documentation and 2) empirically
knowing how things are made by people who follow (1).
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-18 21:57 +0100 |
| Message-ID | <ueadjl$1uhr4$1@dont-email.me> |
| In reply to | #175940 |
On 18/09/2023 20:55, Kaz Kylheku wrote:
> On 2023-09-18, Bart <bc@freeuk.com> 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) {}
>
> The const here makes no difference.
Well, yeah, I changed those {} to ; precisely because someone would say
that, but I forgot to repaste it.
In any case, in such examples, you have to assume the the contents of {}
could be anything, not literally empty bodies.
> Since this is a definition, the compiler can inline the function, and
> make it disappear, since it does nothing.
>
>> 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.
>
> Suppose that bill is an external function, which is declared like
> this:
>
> void bill(const date d);
>
> that const means nothing and can (really, should) be ignored.
>
> The function definition can look like:
>
> void bill(date d) { /*...*/ }
>
> or like:
>
> void bill(const date d) { /*...*/ }
>
> both of these are correct, and their ABI must be exactly the same.
>
>> Although this is nothing really to do with optimisation, just common sense.
>
> Common sense is no substitute for 1) documentation and 2) empirically
> knowing how things are made by people who follow (1).
So what would you do if generating code for:
bill(dd);
when the body of bill() is not visible; would you make a copy of the
struct of not? Bear in a mind that while this struct is only 12 bytes,
another might be 0.5MB in size, and copying it on each of millions of
calls would be a major overhead.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-18 14:00 -0700 |
| Message-ID | <ueadq3$1uk16$2@dont-email.me> |
| In reply to | #175944 |
On 9/18/2023 1:57 PM, Bart wrote:
> On 18/09/2023 20:55, Kaz Kylheku wrote:
>> On 2023-09-18, Bart <bc@freeuk.com> 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) {}
>>
>> The const here makes no difference.
>
> Well, yeah, I changed those {} to ; precisely because someone would say
> that, but I forgot to repaste it.
>
> In any case, in such examples, you have to assume the the contents of {}
> could be anything, not literally empty bodies.
>
>> Since this is a definition, the compiler can inline the function, and
>> make it disappear, since it does nothing.
>>
>>> 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.
>>
>> Suppose that bill is an external function, which is declared like
>> this:
>>
>> void bill(const date d);
>>
>> that const means nothing and can (really, should) be ignored.
>>
>> The function definition can look like:
>>
>> void bill(date d) { /*...*/ }
>>
>> or like:
>>
>> void bill(const date d) { /*...*/ }
>>
>> both of these are correct, and their ABI must be exactly the same.
>>
>>> Although this is nothing really to do with optimisation, just common
>>> sense.
>>
>> Common sense is no substitute for 1) documentation and 2) empirically
>> knowing how things are made by people who follow (1).
>
> So what would you do if generating code for:
>
> bill(dd);
>
> when the body of bill() is not visible; would you make a copy of the
> struct of not? Bear in a mind that while this struct is only 12 bytes,
> another might be 0.5MB in size, and copying it on each of millions of
> calls would be a major overhead.
>
>
>
Dr. Optimization wrt the compiler can help us here?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-18 21:26 +0000 |
| Message-ID | <20230918142049.635@kylheku.com> |
| In reply to | #175944 |
On 2023-09-18, Bart <bc@freeuk.com> wrote:
> On 18/09/2023 20:55, Kaz Kylheku wrote:
>> On 2023-09-18, Bart <bc@freeuk.com> 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) {}
>>
>> The const here makes no difference.
>
> Well, yeah, I changed those {} to ; precisely because someone would say
> that, but I forgot to repaste it.
>
> In any case, in such examples, you have to assume the the contents of {}
> could be anything, not literally empty bodies.
>
>> Since this is a definition, the compiler can inline the function, and
>> make it disappear, since it does nothing.
>>
>>> 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.
>>
>> Suppose that bill is an external function, which is declared like
>> this:
>>
>> void bill(const date d);
>>
>> that const means nothing and can (really, should) be ignored.
>>
>> The function definition can look like:
>>
>> void bill(date d) { /*...*/ }
>>
>> or like:
>>
>> void bill(const date d) { /*...*/ }
>>
>> both of these are correct, and their ABI must be exactly the same.
>>
>>> Although this is nothing really to do with optimisation, just common sense.
>>
>> Common sense is no substitute for 1) documentation and 2) empirically
>> knowing how things are made by people who follow (1).
>
> So what would you do if generating code for:
>
> bill(dd);
>
> when the body of bill() is not visible; would you make a copy of the
> struct of not?
If I had make sure that it's compatible with another compiler or
platform ABI, then I would research into their rules.
If I could implement it from scratch, I would probably pass very small
structures as several register arguments, if registers are available
in light of other arguments. In other cases by address.
Since that address is never declared as a pointer argument, const
doesn't enter into the picture.
It has to look like pass-by-value, so the caller cannot modify the
object. The function definition is compiled such that if the structure
is modified, or its address is taken such that we cannot prove that it's
not modified elsewhere, then we generate code to make a copy. The stack
frame is extended by enough space to provide the storage for the copy,
etc.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-18 15:55 -0700 |
| Message-ID | <871qevks5n.fsf@nosuchdomain.example.com> |
| In reply to | #175944 |
Bart <bc@freeuk.com> writes:
> On 18/09/2023 20:55, Kaz Kylheku wrote:
>> On 2023-09-18, Bart <bc@freeuk.com> wrote:
[...]
>>> If you take a program like this:
>>>
>>> typedef struct {int d,m,y;} date;
>>>
>>> void fred(date d) {}
>>> void bill(const date d) {}
>> The const here makes no difference.
>
> Well, yeah, I changed those {} to ; precisely because someone would
> say that, but I forgot to repaste it.
>
> In any case, in such examples, you have to assume the the contents of
> {} could be anything, not literally empty bodies.
[...]
You posted valid code (with two empty function bodies), and it's
reasonable to assume that you were referring to that exact code.
If you want to indicate that the bodies might not be empty, I
suggest something like:
void fred(date d) {...}
void bill(const date d) {...}
or
void fred(date d) { /* ... */ }
void bill(const date d) { /* ... */ }
Of course if you had posted with ; rather than {} as you intended, that
would have been different -- but we can only see what you actually post,
not what you mean.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-19 09:33 +0200 |
| Message-ID | <uebiso$28ata$2@dont-email.me> |
| In reply to | #175944 |
On 18/09/2023 22:57, Bart wrote:
> On 18/09/2023 20:55, Kaz Kylheku wrote:
>> On 2023-09-18, Bart <bc@freeuk.com> 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) {}
>>
>> The const here makes no difference.
>
> Well, yeah, I changed those {} to ; precisely because someone would say
> that, but I forgot to repaste it.
>
> In any case, in such examples, you have to assume the the contents of {}
> could be anything, not literally empty bodies.
>
>> Since this is a definition, the compiler can inline the function, and
>> make it disappear, since it does nothing.
>>
>>> 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.
>>
>> Suppose that bill is an external function, which is declared like
>> this:
>>
>> void bill(const date d);
>>
>> that const means nothing and can (really, should) be ignored.
>>
>> The function definition can look like:
>>
>> void bill(date d) { /*...*/ }
>>
>> or like:
>>
>> void bill(const date d) { /*...*/ }
>>
>> both of these are correct, and their ABI must be exactly the same.
>>
>>> Although this is nothing really to do with optimisation, just common
>>> sense.
>>
>> Common sense is no substitute for 1) documentation and 2) empirically
>> knowing how things are made by people who follow (1).
>
> So what would you do if generating code for:
>
> bill(dd);
>
> when the body of bill() is not visible; would you make a copy of the
> struct of not? Bear in a mind that while this struct is only 12 bytes,
> another might be 0.5MB in size, and copying it on each of millions of
> calls would be a major overhead.
>
By "you", do you mean the compiler? Yes, the compiler needs to make a
copy if the original "dd" is needed later. And if it does not have
access to the definition of "bill" (it's in a separately compiled unit),
it needs to follow the ABI - typically for large structures, that means
copying it onto the stack. (For some targets, it may mean passing a
hidden pointer to a copy that does not have to be on the stack - that's
up to the target ABI.)
If the compiler has access to the definition of "bill" and is handling
the compilation of the two parts together, it's a different story. Then
it can merge code, inline code, use information about whether "bill"
actually changes "dd" or not, use any calling convention it wants, and
so on. Whole-program optimisation (or link-time-optimisation - there
are many names) gives the compiler a lot of freedom. But regardless, it
must always give the same end results as though "dd" were copied.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-18 21:59 +0200 |
| Message-ID | <ueaa7e$1tugo$1@dont-email.me> |
| In reply to | #175935 |
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".
>
> This is to avoid changes made to 'd' inside the caller from affecting
> the caller's data.
>
> Although this is nothing really to do with optimisation, just common
> sense.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-18 22:01 +0100 |
| Message-ID | <ueadqt$1uhr4$2@dont-email.me> |
| In reply to | #175941 |
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?
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?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-18 22:16 +0100 |
| Message-ID | <87pm2fi3mf.fsf@bsb.me.uk> |
| In reply to | #175946 |
Bart <bc@freeuk.com> writes:
> So, basically, 'const' can never be trusted?
No.
> 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?
The object has a const-qualified type. It can not be altered except in
a way that results in undefined behaviour meaning that a compiler is
allowed to assume that it has not changed. (Of course, it also means
that a compiler can ignore the const if that makes sense for that
particular implementation.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-18 15:51 -0700 |
| Message-ID | <875y47ksdg.fsf@nosuchdomain.example.com> |
| In reply to | #175946 |
Bart <bc@freeuk.com> writes:
> On 18/09/2023 20:59, David Brown wrote:
[...]
>> 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"***.
Emphasis added.
> So, basically, 'const' can never be trusted?
No.
> 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?
No, see above. The original object was defined as "const".
--
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-18 22:59 +0000 |
| Message-ID | <20230918142634.194@kylheku.com> |
| In reply to | #175946 |
On 2023-09-18, Bart <bc@freeuk.com> wrote:
> On 18/09/2023 20:59, David Brown wrote:
>> 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?
A const qualifier on a function parameter (the parameter itself,
not what it points to) means nothing as far as declaring anything
to a caller.
It's active in definitions. In a function definition, parameters are
local variables, and that's how you make the parameter const.
It can be repeated in the declaration, but means nothing.
ISO C says something like thaat for the purposes of determining whether
two function types are compatible, qualifiers on the parameters are
ignored.
These two pointers have exactly the same type:
void (*p1)(const int);
void (*p2)(int);
You shouldn't put const qualifiers on parameters in declarations; since
they are ignored, it can only lead to confusion on the part of someone
who doesn't know about this quirk or has forgotten about it.
> 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?
It can; abc isn't a parameter involved in determining function
compatibility, so that isn't a situation in which const is ignored.
Here the const means that assigning a value to abc is a constraint
violation, and modifying abc in some underhanded way like
*(int *)(&abc) = 0;
is undefined behavior. The compiler can assue that abc holds 100 on the
principle of assuming that no undefined behavior took place.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-18 16:04 -0700 |
| Message-ID | <ueal14$1vvcp$2@dont-email.me> |
| In reply to | #175963 |
On 9/18/2023 3:59 PM, Kaz Kylheku wrote: > On 2023-09-18, Bart <bc@freeuk.com> wrote: >> On 18/09/2023 20:59, David Brown wrote: >>> 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? > > A const qualifier on a function parameter (the parameter itself, > not what it points to) means nothing as far as declaring anything > to a caller.[...] A const is just a hint to the programmer, in a sense? ct_foobar const* const self; seems to get the "intent" across?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-18 16:19 -0700 |
| Message-ID | <87wmwnjch6.fsf@nosuchdomain.example.com> |
| In reply to | #175965 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
[...]
>> A const qualifier on a function parameter (the parameter itself,
>> not what it points to) means nothing as far as declaring anything
>> to a caller.[...]
>
> A const is just a hint to the programmer, in a sense?
Only when it's applied to a function parameter in a function declaration
that is not part of a function definition.
> ct_foobar const* const self;
>
> seems to get the "intent" across?
That means that `self` is a const pointer to const `ct_foobar`, where
`ct_foobar` is a type. Both occurrences of `const` impose constraints
on code that refers to self. If that's the "intent", then yes, it gets
it across.
Note that this is not a parameter declaration (if it were, the semicolon
would be a syntax error), so it's not directly relevant to the current
discussion.
If it were a parameter declaration, then the second `const` (which makes
`self` itself a const object) would impose no constraints on callers,
but if the function declaration were part of a function definition, it
would impose a constraint on code inside the function.
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-18 16:24 -0700 |
| Message-ID | <ueam6o$206cj$1@dont-email.me> |
| In reply to | #175966 |
On 9/18/2023 4:19 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
> [...]
>>> A const qualifier on a function parameter (the parameter itself,
>>> not what it points to) means nothing as far as declaring anything
>>> to a caller.[...]
>>
>> A const is just a hint to the programmer, in a sense?
>
> Only when it's applied to a function parameter in a function declaration
> that is not part of a function definition.
>
>> ct_foobar const* const self;
>>
>> seems to get the "intent" across?
>
> That means that `self` is a const pointer to const `ct_foobar`, where
> `ct_foobar` is a type. Both occurrences of `const` impose constraints
> on code that refers to self. If that's the "intent", then yes, it gets
> it across.
>
> Note that this is not a parameter declaration (if it were, the semicolon
> would be a syntax error), so it's not directly relevant to the current
> discussion.
void
ct_foo(
ct_foobar* const self
){
// self "cannot" be changed... So be it!
}
vs:
void
ct_foo(
ct_foobar const* const self
){
// self "cannot" be changed... So be it!
// the ct_foobar that self points to is const...
}
Any better?
>
> If it were a parameter declaration, then the second `const` (which makes
> `self` itself a const object) would impose no constraints on callers,
> but if the function declaration were part of a function definition, it
> would impose a constraint on code inside the function.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-18 16:44 -0700 |
| Message-ID | <87sf7bjbcl.fsf@nosuchdomain.example.com> |
| In reply to | #175967 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 9/18/2023 4:19 PM, Keith Thompson wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
>> [...]
>>>> A const qualifier on a function parameter (the parameter itself,
>>>> not what it points to) means nothing as far as declaring anything
>>>> to a caller.[...]
>>>
>>> A const is just a hint to the programmer, in a sense?
>> Only when it's applied to a function parameter in a function
>> declaration
>> that is not part of a function definition.
>>
>>> ct_foobar const* const self;
>>>
>>> seems to get the "intent" across?
>> That means that `self` is a const pointer to const `ct_foobar`,
>> where `ct_foobar` is a type. Both occurrences of `const` impose
>> constraints on code that refers to self. If that's the "intent",
>> then yes, it gets it across.
>>
>> Note that this is not a parameter declaration (if it were, the
>> semicolon would be a syntax error), so it's not directly relevant to
>> the current discussion.
>
> void
> ct_foo(
> ct_foobar* const self
> ){
> // self "cannot" be changed... So be it!
> }
Attempting to modify self directly, for example `self = NULL;`, is a
constraint violation. Attempting to modify self indirectly, for example
`*(ct_foobar*)self = NULL;` has undefined behavior.
> vs:
>
> void
> ct_foo(
> ct_foobar const* const self
> ){
> // self "cannot" be changed... So be it!
> // the ct_foobar that self points to is const...
> }
>
> Any better?
[...]
And in both cases, the fact that the parameter `self` is const does not
affect callers.
Better for what purpose?
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-18 17:37 -0700 |
| Message-ID | <ueaqgb$20t4i$1@dont-email.me> |
| In reply to | #175969 |
On 9/18/2023 4:44 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 9/18/2023 4:19 PM, Keith Thompson wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 9/18/2023 3:59 PM, Kaz Kylheku wrote:
>>> [...]
>>>>> A const qualifier on a function parameter (the parameter itself,
>>>>> not what it points to) means nothing as far as declaring anything
>>>>> to a caller.[...]
>>>>
>>>> A const is just a hint to the programmer, in a sense?
>>> Only when it's applied to a function parameter in a function
>>> declaration
>>> that is not part of a function definition.
>>>
>>>> ct_foobar const* const self;
>>>>
>>>> seems to get the "intent" across?
>>> That means that `self` is a const pointer to const `ct_foobar`,
>>> where `ct_foobar` is a type. Both occurrences of `const` impose
>>> constraints on code that refers to self. If that's the "intent",
>>> then yes, it gets it across.
>>>
>>> Note that this is not a parameter declaration (if it were, the
>>> semicolon would be a syntax error), so it's not directly relevant to
>>> the current discussion.
>>
>> void
>> ct_foo(
>> ct_foobar* const self
>> ){
>> // self "cannot" be changed... So be it!
>> }
>
> Attempting to modify self directly, for example `self = NULL;`, is a
> constraint violation. Attempting to modify self indirectly, for example
> `*(ct_foobar*)self = NULL;` has undefined behavior.
>
>> vs:
>>
>> void
>> ct_foo(
>> ct_foobar const* const self
>> ){
>> // self "cannot" be changed... So be it!
>> // the ct_foobar that self points to is const...
>> }
>>
>> Any better?
> [...]
>
> And in both cases, the fact that the parameter `self` is const does not
> affect callers.
>
> Better for what purpose?
>
Better to try to convey to a reader that this intent is meant, or else
be there nasal demons... ?
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web