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 1 of 10 [1] 2 3 … 10 Next page →
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-18 01:21 +0300 |
| Subject | Do you insist on const-correctness? |
| Message-ID | <20230918012105.b9fb2c36e93542dddb654b1f@gmail.moc> |
Hello, all.
This is my function for setting the length of a dynamic
array:
void* a_setlen( void * a, unsigned len )
{ unsigned newcap;
struct meta_t *m ;
m = META ( a );
m = setlen( m, len );
if( m != NULL ) a = DATA( m );
else a = NULL ;
return a;
}
To allow for a potential reallocation, it returns an updated
pointer to the array. Although it is small, and therefore
easily understandable at a glance as is, I am taught and
told that it smells bad, because of the reuse an input
variable to store the new value to be returned. Is it the
undubitable consensus that one shall redefine this function
as:
void* a_setlen( const void * const a, const unsigned len )
{ unsigned newcap;
struct meta_t *m ;
void *res ;
m = META ( a );
m = setlen( m, len );
if( m != NULL ) res = DATA( m );
else res = NULL ;
return res;
}
especially considering that it is a `public' function,
available to the programmer using the library? I personally
find pervasive const-correctenss a source of noise and
clutter, what do you think?
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-18 01:23 +0300 |
| Message-ID | <20230918012343.850e4d22f1a10d589fc52244@gmail.moc> |
| In reply to | #175828 |
I wrote:
> This is my function for setting the length of a dynamic
> array:
>
> void* a_setlen( void * a, unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) a = DATA( m );
> else a = NULL ;
> return a;
> }
Please, disregard the unused variable `newcap'.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-18 00:32 +0100 |
| Message-ID | <878r94l6jj.fsf@bsb.me.uk> |
| In reply to | #175828 |
Anton Shepelev <anton.txt@gmail.moc> writes:
> Hello, all.
>
> This is my function for setting the length of a dynamic
> array:
>
> void* a_setlen( void * a, unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) a = DATA( m );
> else a = NULL ;
> return a;
> }
>
> To allow for a potential reallocation, it returns an updated
> pointer to the array. Although it is small, and therefore
> easily understandable at a glance as is, I am taught and
> told that it smells bad, because of the reuse an input
> variable to store the new value to be returned. Is it the
> undubitable consensus that one shall redefine this function
> as:
>
> void* a_setlen( const void * const a, const unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
> void *res ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) res = DATA( m );
> else res = NULL ;
> return res;
> }
>
> especially considering that it is a `public' function,
> available to the programmer using the library? I personally
> find pervasive const-correctenss a source of noise and
> clutter, what do you think?
I have never bothered with const on parameters since it has no effect on
the caller, but I am puzzled by the const void *a. If this function
does what I think it does, the target of the pointer is altered. Mind
you, the macros are masking what's happening, but the function name
suggests are change to the target albeit through an opaque pointer.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2023-09-18 10:55 +0300 |
| Message-ID | <20230918105557.34ccda4e0c85b711a58302ab@g{oogle}mail.com> |
| In reply to | #175830 |
Ben Bacarisse to Anton Shepelev:
> > void* a_setlen( void * a, unsigned len )
> > { unsigned newcap;
> > struct meta_t *m ;
> >
> > m = META ( a );
> > m = setlen( m, len );
> > if( m != NULL ) a = DATA( m );
> > else a = NULL ;
> > return a;
> > }
>
> I have never bothered with const on parameters since it
> has no effect on the caller,
Yes, it prevents the function body from modifying a
parameter, `a' in my case.
> but I am puzzled by the const void *a. If this function
> does what I think it does,
Did you read or watch Princess Bride?
> the target of the pointer is altered.
Well, `a' points to the start of array data, whereas what I
(perhaps incorrectly) call its metadata is located at a
negative offset, is indeed changed by the function, but is
not literally pointed to by `a'. The array data may be
reallocated as well, but the value of `*a' (with propor
cast) will still be the first element of the array. Or
should I say it will be changed because `a' will be
pointing, in general, to an object of a different size and
at a different address, albeit with the same initial
contents?
> Mind you, the macros are masking what's happening, but the
> function name suggests are change to the target albeit
> through an opaque pointer.
The META macro retrievies the pointer to the metadata object
(and the entire allocated memory object) by subtracting an
offset from the pointer to array data.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-18 13:40 +0200 |
| Message-ID | <ue9cv4$1ob5a$1@dont-email.me> |
| In reply to | #175865 |
On 18/09/2023 09:55, Anton Shepelev wrote:
> Ben Bacarisse to Anton Shepelev:
>
>>> void* a_setlen( void * a, unsigned len )
>>> { unsigned newcap;
>>> struct meta_t *m ;
>>>
>>> m = META ( a );
>>> m = setlen( m, len );
>>> if( m != NULL ) a = DATA( m );
>>> else a = NULL ;
>>> return a;
>>> }
>>
>> I have never bothered with const on parameters since it
>> has no effect on the caller,
>
> Yes, it prevents the function body from modifying a
> parameter, `a' in my case.
That's an implementation matter, rather than part of the interface of
the function. Inside the function definition, the parameters are like
local variables - the implementation can do what it wants with them, and
they don't affect the caller at all.
The way I look at it, is that since it is not relevant to the caller, it
should not be in the function declaration - it adds nothing, but could
potentially be misread ("int * const p" could be misread, thinking it
meant "int const * p"). And I always want all my declarations to match
- my extern function declarations in headers are identical to the
declaration at the start of the function definition.
Usually I don't want my functions to modify the parameters (there are
exceptions, typically for very small functions). But I find "const"
does not help enough to make it worth using here.
>
>> but I am puzzled by the const void *a. If this function
>> does what I think it does,
>
> Did you read or watch Princess Bride?
>
>> the target of the pointer is altered.
>
> Well, `a' points to the start of array data, whereas what I
> (perhaps incorrectly) call its metadata is located at a
> negative offset, is indeed changed by the function, but is
> not literally pointed to by `a'. The array data may be
> reallocated as well, but the value of `*a' (with propor
> cast) will still be the first element of the array. Or
> should I say it will be changed because `a' will be
> pointing, in general, to an object of a different size and
> at a different address, albeit with the same initial
> contents?
This is a typical conflict between "bitwise const" and "logical const" -
you have something whose value, as seen by code using the object, does
not change, although the implementation details and the bits held in the
object /do/ change. You see it also with objects that cache the results
of calculations, or self-optimising lists that move recently accessed
data to the front of the list.
C does not really have a good way to handle this. (C++ has "mutable"
class members, which helps here.) You can have a const pointer to your
dynamic array, where the array object is a struct with a non-const
pointer to the metadata, and a non-const pointer to the data. Then you
can change the metadata even though the parameter is a const pointer.
You can also take a const pointer as a way to indicate to the caller
that you are making no logical changes to the object. Then simply cast
it to a non-const pointer before doing the changes. This is allowed in
C if you can be sure that the function will never be called with an
object that was originally defined as "const". Whether you consider
this as giving the caller useful information while hiding the
implementation details, or as lying to the caller, is up to you.
>
>> Mind you, the macros are masking what's happening, but the
>> function name suggests are change to the target albeit
>> through an opaque pointer.
>
> The META macro retrievies the pointer to the metadata object
> (and the entire allocated memory object) by subtracting an
> offset from the pointer to array data.
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-18 06:02 -0700 |
| Message-ID | <5bd9dd1f-93ca-434a-b9aa-65d7229f85ean@googlegroups.com> |
| In reply to | #175888 |
On Monday, 18 September 2023 at 12:40:38 UTC+1, David Brown wrote: > > Usually I don't want my functions to modify the parameters (there are > exceptions, typically for very small functions). But I find "const" > does not help enough to make it worth using here. > Modifying a parameter is a micro-optimisation, which is almost always a bad idea. Just occasionally code is so critical that you have to do it, though modern compilers will usually do this sort of optimisation for you. The other problem is that the natural name of the parameter and the natural name of the variable which initially takes the value of that parameter are often the same thing. So you have to think carefully about your naming. > > This is a typical conflict between "bitwise const" and "logical const" - > you have something whose value, as seen by code using the object, does > not change, although the implementation details and the bits held in the > object /do/ change. You see it also with objects that cache the results > of calculations, or self-optimising lists that move recently accessed > data to the front of the list. > > C does not really have a good way to handle this. (C++ has "mutable" > class members, which helps here.) You can have a const pointer to your > dynamic array, where the array object is a struct with a non-const > pointer to the metadata, and a non-const pointer to the data. Then you > can change the metadata even though the parameter is a const pointer. > > You can also take a const pointer as a way to indicate to the caller > that you are making no logical changes to the object. Then simply cast > it to a non-const pointer before doing the changes. This is allowed in > C if you can be sure that the function will never be called with an > object that was originally defined as "const". Whether you consider > this as giving the caller useful information while hiding the > implementation details, or as lying to the caller, is up to you. > Say we've got a function called addemployee(PAYROLL *p, EMPLOYEE *employee); Now someone says "We can only have one chief secretary. So let's modify addemployee to delete the old chief secretary from the list if another one is added." Clearly this is a catastrophic approach to program design. A function called addemployee() mustn't delete any employees. But this doesn't differ in principle from a function called compareseniority() that compares two ekmployeees for seniority. Clearly, the act of comparing them shouldn't cause any change. If you need to break ties by giving two employees with equal salary and service length a flag to say "I'm notionally more senior than her for the purposes of the sort", then it should be called something else. A function that violates expectations around const, like the tie-breaking flag setting compare, isn't really any different from a function which violates expectations in other ways, like the addemployee() function which also deletes employees. So const isn't really adding much. It picks up a subset of ways in which the function contract could be violated, but that is all. And it is far better to not use it at all than to have "semi-const" or "logically const" concepts, where const is used but doesn't actually mean what it conventionally means.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-18 17:10 +0200 |
| Message-ID | <ue9p8d$1qfvq$2@dont-email.me> |
| In reply to | #175892 |
On 18/09/2023 15:02, Malcolm McLean wrote: > On Monday, 18 September 2023 at 12:40:38 UTC+1, David Brown wrote: >> >> Usually I don't want my functions to modify the parameters (there are >> exceptions, typically for very small functions). But I find "const" >> does not help enough to make it worth using here. >> > Modifying a parameter is a micro-optimisation, which is almost always a > bad idea. I agree that micro-optimisations are usually not worth the effort, and can be actively bad if they make the code less clear. But I would not consider modifying a parameter to be a micro-optimisation - I expect the compiler to generate identical code if I modify the parameter or if I make a copy and modify that. Any such optimisations are the compiler's job, not the programmers'. > Just occasionally code is so critical that you have to do it, though > modern compilers will usually do this sort of optimisation for you. It's very rare that you have to write performance-critical code and have such a poor quality compiler that it won't sort this kind of optimisation for you. > The other problem is that the natural name of the parameter and the natural > name of the variable which initially takes the value of that parameter are > often the same thing. So you have to think carefully about your naming. Always think about your naming. > >> >> This is a typical conflict between "bitwise const" and "logical const" - >> you have something whose value, as seen by code using the object, does >> not change, although the implementation details and the bits held in the >> object /do/ change. You see it also with objects that cache the results >> of calculations, or self-optimising lists that move recently accessed >> data to the front of the list. >> >> C does not really have a good way to handle this. (C++ has "mutable" >> class members, which helps here.) You can have a const pointer to your >> dynamic array, where the array object is a struct with a non-const >> pointer to the metadata, and a non-const pointer to the data. Then you >> can change the metadata even though the parameter is a const pointer. >> >> You can also take a const pointer as a way to indicate to the caller >> that you are making no logical changes to the object. Then simply cast >> it to a non-const pointer before doing the changes. This is allowed in >> C if you can be sure that the function will never be called with an >> object that was originally defined as "const". Whether you consider >> this as giving the caller useful information while hiding the >> implementation details, or as lying to the caller, is up to you. >> > Say we've got a function called > > addemployee(PAYROLL *p, EMPLOYEE *employee); > Now someone says "We can only have one chief secretary. So let's modify > addemployee to delete the old chief secretary from the list if another one > is added." Clearly this is a catastrophic approach to program design. A > function called addemployee() mustn't delete any employees. > > But this doesn't differ in principle from a function called compareseniority() > that compares two ekmployeees for seniority. Clearly, the act of comparing them > shouldn't cause any change. If you need to break ties by giving two employees > with equal salary and service length a flag to say "I'm notionally more senior than > her for the purposes of the sort", then it should be called something else. I don't get your point at all. Functions should do what they say they do, and functions that shouldn't change their parameters should not change them. That's all obvious, and not related to what I was writing about. And I don't follow your idea of a "tie-breaking flag" - that seems a really strange concept. If you have some way to order the two items (employees, in this case), you don't need a flag. If there is no way to order them, it doesn't matter. The kind of "logical const, bitwise non-const" change you might see in real code is when you have an unsorted list, and a function that finds items on the list. If the code is such that it's likely that you will need the same item again soon, you might want to keep the list in a "last recently used" order - when you find an item, you pull it out to the front of the list. The list is logically unchanged - it's still the same set of data - but the metadata has changed. Clearly when you are doing this kind of thing, you need to be strict about how you access the data - C++'s separation of public and private data and methods provides better control than C can enforce. (I am not giving any guidance as to whether it is best to use "const" or not with such data structures in C, as I think it will depend on many factors.) > > A function that violates expectations around const, like the tie-breaking flag > setting compare, isn't really any different from a function which violates > expectations in other ways, like the addemployee() function which also > deletes employees. So const isn't really adding much. It picks up a > subset of ways in which the function contract could be violated, but > that is all. > And it is far better to not use it at all than to have "semi-const" or > "logically const" concepts, where const is used but doesn't actually mean > what it conventionally means. Why is using "const" (telling the user "I won't change your data") when you mean "logically const" worse than using non-const (telling the user "Beware - I'm going to change your data") when you are /not/ going to change it? C won't let you say exactly what you mean either way.
[toc] | [prev] | [next] | [standalone]
| From | "comp.lang.c" <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-18 16:47 -0700 |
| Message-ID | <91bd7759-54ae-40c9-bd0b-0f352224cc53n@googlegroups.com> |
| In reply to | #175910 |
On Monday, 18 September 2023 at 16:10:23 UTC+1, David Brown wrote: > On 18/09/2023 15:02, Malcolm McLean wrote: > > > And it is far better to not use it at all than to have "semi-const" or > > "logically const" concepts, where const is used but doesn't actually mean > > what it conventionally means. > Why is using "const" (telling the user "I won't change your data") when > you mean "logically const" worse than using non-const (telling the user > "Beware - I'm going to change your data") when you are /not/ going to > change it? C won't let you say exactly what you mean either way. > Firstly, const obviously means "this won't change", but there's no "mutated" keyword to mean "this will change" or this will change". Non-const items are simply not declared const. You can assume that they may change if and only if the project has a policy of "const correctness". And even then, where const means "this won't change", non-const only means "this changes on some execution path". Which may be excluded by the other parameters. It doesn't mean that the object will change. So it's not symmetrical. If you have a policy of exclusing const then all the problems simply disappear. You have to document which functions change objects passed by pointer, if and only if they are transparent pointers and it's any business of callers. But it's the rare function where the pointer is transparent, but any documentation worthy of the name wouldn't say what state the object is left in after the function returns.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-19 09:25 +0200 |
| Message-ID | <uebid6$28ata$1@dont-email.me> |
| In reply to | #175970 |
On 19/09/2023 01:47, comp.lang.c wrote: (Malcolm, you've mixed up your Google Groups settings somewhere, and given yourself the name "comp.lang.c". ) > On Monday, 18 September 2023 at 16:10:23 UTC+1, David Brown wrote: >> On 18/09/2023 15:02, Malcolm McLean wrote: >> >>> And it is far better to not use it at all than to have "semi-const" or >>> "logically const" concepts, where const is used but doesn't actually mean >>> what it conventionally means. >> Why is using "const" (telling the user "I won't change your data") when >> you mean "logically const" worse than using non-const (telling the user >> "Beware - I'm going to change your data") when you are /not/ going to >> change it? C won't let you say exactly what you mean either way. >> > Firstly, const obviously means "this won't change", but there's no "mutated" > keyword to mean "this will change" or this will change". That's not what "const" means in C. But we can fully agree that there is no "mutated" keyword or other nuanced "sort-of constant" marker in C. (Perhaps one day there will be attributes added for this kind of thing.) > Non-const items > are simply not declared const. You can assume that they may change if > and only if the project has a policy of "const correctness". No, you must /always/ assume that they might change - unless there is documentation guaranteeing that they don't. Even with "const", it is possible for things to change, because you can always cast it away in the implementation of the function. But it is a strong indication to the user that you do not intend to change anything, and you have to go out of your way (such as via a cast) to change things that are marked "const". > And even then, > where const means "this won't change", non-const only means "this changes > on some execution path". Which may be excluded by the other parameters. As we all know, non-const means "may change", not "/will/ change". And "const" means "this won't change unless I really want it to". > It doesn't mean that the object will change. > So it's not symmetrical. It is more symmetric than you think. It is not as clear-cut as you think. And if you have something that does not change in the user-visible aspects (assuming the function user sticks to the defined API), but may change in its internal aspects, there is no fixed rule that says whether the pointer should be marked "const" or left non-const. I would say it must be handled on a case-by-case basis - whatever makes things clearer to the user and reduce their risk of getting things wrong. (And of course the nuances must be documented, since C can't express them.) > If you have a policy of exclusing const then all the problems simply disappear. Give up and run away? C's "const" keyword is not perfect in all use-cases, so you think it is better to miss out entirely? That's a very poor attitude. No tool is ever perfect in all circumstances - that's no excuse for not doing the best you can with what you've got. > You have to document which functions change objects passed by pointer, > if and only if they are transparent pointers and it's any business of callers. Documentation should supplement the code, not replace it. When things can be written in the language, write it in the language - not in comments. > But it's the rare function where the pointer is transparent, but any documentation > worthy of the name wouldn't say what state the object is left in after the function > returns. I'm not sure what you are trying to say here - I'm not sure that /you/ are sure. After all, if a function takes a pointer to an object, the documentation should be very clear about what state the object will be in after the call.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-19 02:57 -0700 |
| Message-ID | <87wmwmiiyt.fsf@nosuchdomain.example.com> |
| In reply to | #176003 |
David Brown <david.brown@hesbynett.no> writes:
> On 19/09/2023 01:47, comp.lang.c wrote:
> (Malcolm, you've mixed up your Google Groups settings somewhere, and
> given yourself the name "comp.lang.c". )
[...]
It's likely something going wrong with Google Groups itself. I've seen
a handful or articles in other newsgroups with headers like
From: "newsgroup.name" <email@address>
(which caused some spam to bypass my filters). I made a test post on GG
that didn't exhibit the issue, so it's probably sporadic.
I'm sure Google's devotion to a smooth integration between Google Groups
and Usenet will lead to a quick solution -- in the fullness of time.
--
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-19 12:31 -0700 |
| Message-ID | <uecsvg$2g3hn$8@dont-email.me> |
| In reply to | #176013 |
On 9/19/2023 2:57 AM, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 19/09/2023 01:47, comp.lang.c wrote: >> (Malcolm, you've mixed up your Google Groups settings somewhere, and >> given yourself the name "comp.lang.c". ) > [...] > > It's likely something going wrong with Google Groups itself. I've seen > a handful or articles in other newsgroups with headers like > > From: "newsgroup.name" <email@address> > > (which caused some spam to bypass my filters). I made a test post on GG > that didn't exhibit the issue, so it's probably sporadic. > > I'm sure Google's devotion to a smooth integration between Google Groups > and Usenet will lead to a quick solution -- in the fullness of time. > in the fullness of time... lol Google says we will get back to you after we are finished counting to infinity on a step-by-step basis... ;^o
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-19 03:54 -0700 |
| Message-ID | <ac441147-85ec-4628-a4b2-b05fc96a0ab4n@googlegroups.com> |
| In reply to | #176003 |
On Tuesday, 19 September 2023 at 08:25:44 UTC+1, David Brown wrote: > On 19/09/2023 01:47, comp.lang.c wrote: > > (Malcolm, you've mixed up your Google Groups settings somewhere, and > given yourself the name "comp.lang.c". ) > I think I'm going to have to bite the bullet and install a newsreader. A shame because Google Groups is in many way the best interface. But it's getting unusable. > > No, you must /always/ assume that they might change - unless there is > documentation guaranteeing that they don't. > It's usually obvious which parameters are input and which are output, and the only documentation you need is the function name. Things aren't formally documented in many programming environments. > > It is more symmetric than you think. It is not as clear-cut as you > think. And if you have something that does not change in the > user-visible aspects (assuming the function user sticks to the defined > API), but may change in its internal aspects, there is no fixed rule > that says whether the pointer should be marked "const" or left > non-const. I would say it must be handled on a case-by-case basis - > whatever makes things clearer to the user and reduce their risk of > getting things wrong. (And of course the nuances must be documented, > since C can't express them.) > And this is a deeply undesireable approach for a programming language keyword. > > > If you have a policy of exclusing const then all the problems simply disappear. > Give up and run away? C's "const" keyword is not perfect in all > use-cases, so you think it is better to miss out entirely? That's a > very poor attitude. No tool is ever perfect in all circumstances - > that's no excuse for not doing the best you can with what you've got. > Just because something is invented doesn't mean that you have to use it. You shouldn't use const on opaque pointers. And there's little benefit in using const on transparent pointers unless it isn't obvious which pointers are modified and which are not. There is a benefit in marking read-only compile time data as const, but again it's slight, as it's not very likely that a program near release would have an error in it which meant it wrote to such data. There are some benefits to const and a rational person can defend its inclusion in C, but they are not very impressive and they don't justify the weight. It's best not used, in code that you control yourself. (The same is not true in C++. Whilst const has its problems there, there are differences in the way that const is defined which make it more useful, and it's also very useful for preventing accidental modification of objects passed by reference). > > You have to document which functions change objects passed by pointer, > > if and only if they are transparent pointers and it's any business of callers. > Documentation should supplement the code, not replace it. When things > can be written in the language, write it in the language - not in comments. > > But it's the rare function where the pointer is transparent, but any documentation > > worthy of the name wouldn't say what state the object is left in after the function > > returns. > I'm not sure what you are trying to say here - I'm not sure that /you/ > are sure. After all, if a function takes a pointer to an object, the > documentation should be very clear about what state the object will be > in after the call. > If the documentation says what state a passed in object is left in on function return, then const is redundant. It's not telling you anything that the documentation doesn't. If the documentation doesn't tell you what state a passed in object is left in on function return, then what is going on? Maybe something weird and wonderful. Transparent objects, of course.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-19 16:54 +0200 |
| Message-ID | <ueccne$2d4ia$1@dont-email.me> |
| In reply to | #176014 |
On 19/09/2023 12:54, Malcolm McLean wrote: > On Tuesday, 19 September 2023 at 08:25:44 UTC+1, David Brown wrote: >> On 19/09/2023 01:47, comp.lang.c wrote: >> >> (Malcolm, you've mixed up your Google Groups settings somewhere, and >> given yourself the name "comp.lang.c". ) >> > I think I'm going to have to bite the bullet and install a newsreader. A shame > because Google Groups is in many way the best interface. But it's getting > unusable. I don't believe I have previously heard someone suggest that Google Groups has the best interface! I do appreciate it has /some/ advantages for some uses (such as searching). >> >> No, you must /always/ assume that they might change - unless there is >> documentation guaranteeing that they don't. >> > It's usually obvious which parameters are input and which are output, > and the only documentation you need is the function name. Things aren't > formally documented in many programming environments. Informal documentation - comments in the code - is often fine. > > >> It is more symmetric than you think. It is not as clear-cut as you >> think. And if you have something that does not change in the >> user-visible aspects (assuming the function user sticks to the defined >> API), but may change in its internal aspects, there is no fixed rule >> that says whether the pointer should be marked "const" or left >> non-const. I would say it must be handled on a case-by-case basis - >> whatever makes things clearer to the user and reduce their risk of >> getting things wrong. (And of course the nuances must be documented, >> since C can't express them.) >> > And this is a deeply undesireable approach for a programming language > keyword. It is not ideal, certainly - but not nearly the problem you make it out to be. >> >>> If you have a policy of exclusing const then all the problems simply disappear. >> Give up and run away? C's "const" keyword is not perfect in all >> use-cases, so you think it is better to miss out entirely? That's a >> very poor attitude. No tool is ever perfect in all circumstances - >> that's no excuse for not doing the best you can with what you've got. >> > Just because something is invented doesn't mean that you have to use it. Agreed. But just because something is imperfect in some cases, does not mean you should never use it. "const" is extremely helpful - it is helpful to the people writing the function (by catching mistakes), and helpful to the people using the function (by making the use of parameters clearer). The compiler is not able to assume pointer-to-const parameters are never cast to non-const pointers, but the user of the function might be able to do so. > You shouldn't use const on opaque pointers. You should avoid /anything/ opaque when programming. Every use of "void *" or "const void *" should be questioned. It /might/ be the best choice for the task in hand, but often it is laziness. Regardless, if you know you will not change anything via a pointer parameter, mark it "const". > And there's little benefit in > using const on transparent pointers unless it isn't obvious which pointers > are modified and which are not. At the risk of repeating myself ad nauseum, /yes/ you want to mark pointers as "const" if you are not going to change anything via them. If you want to know why, re-read my previous posts, or google for it. Obviously you write your own code the way you want, but I recommend you join the current century, and maybe learn a bit of modern software development. The programming world has improved.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-19 12:33 -0700 |
| Message-ID | <uect1e$2g3hn$9@dont-email.me> |
| In reply to | #176031 |
On 9/19/2023 7:54 AM, David Brown wrote: > On 19/09/2023 12:54, Malcolm McLean wrote: >> On Tuesday, 19 September 2023 at 08:25:44 UTC+1, David Brown wrote: >>> On 19/09/2023 01:47, comp.lang.c wrote: >>> >>> (Malcolm, you've mixed up your Google Groups settings somewhere, and >>> given yourself the name "comp.lang.c". ) >>> >> I think I'm going to have to bite the bullet and install a newsreader. >> A shame >> because Google Groups is in many way the best interface. But it's getting >> unusable. > > I don't believe I have previously heard someone suggest that Google > Groups has the best interface! I do appreciate it has /some/ advantages > for some uses (such as searching). [...] Searching is pretty good wrt google groups, however its interface is another story... ;^o
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-19 14:56 -0700 |
| Message-ID | <87sf79j07p.fsf@nosuchdomain.example.com> |
| In reply to | #176014 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 19 September 2023 at 08:25:44 UTC+1, David Brown wrote:
>> On 19/09/2023 01:47, comp.lang.c wrote:
>> (Malcolm, you've mixed up your Google Groups settings somewhere, and
>> given yourself the name "comp.lang.c". )
>>
> I think I'm going to have to bite the bullet and install a
> newsreader. A shame because Google Groups is in many way the best
> interface. But it's getting unusable.
Your most recent article showed your correct name in the header. It's
possible that the problem has been corrected. (I presume you haven't
changed your configuration in the last few days.)
Using a newsreader rather than posting through Google Groups is probably
a good idea for other reasons. For one thing, a lot of people filter
out all posts from Google Groups (with or without a whitelist for
specific posters).
If you decide to use an NNTP server and newsreader, eternal-september.org
is pretty good and is the only surviving free NNTP server I know of
(aioe.org appears to be dead). I recommend Gnus if **and only if**
you're comfortable with Emacs; otherwise, Thunderbird seems to be
popular.
[...]
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-19 13:43 +0000 |
| Message-ID | <eAhOM.7294$H0Ge.6208@fx05.iad> |
| In reply to | #176003 |
David Brown <david.brown@hesbynett.no> writes: >On 19/09/2023 01:47, comp.lang.c wrote: > >(Malcolm, you've mixed up your Google Groups settings somewhere, and >given yourself the name "comp.lang.c". ) I've seen posts in other groups that imply this is a new "feature" of the google groups interface.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-18 12:49 +0100 |
| Message-ID | <87r0mvk8ex.fsf@bsb.me.uk> |
| In reply to | #175865 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Ben Bacarisse to Anton Shepelev:
>
>> > void* a_setlen( void * a, unsigned len )
>> > { unsigned newcap;
>> > struct meta_t *m ;
>> >
>> > m = META ( a );
>> > m = setlen( m, len );
>> > if( m != NULL ) a = DATA( m );
>> > else a = NULL ;
>> > return a;
>> > }
>>
>> I have never bothered with const on parameters since it
>> has no effect on the caller,
>
> Yes, it prevents the function body from modifying a
> parameter, `a' in my case.
>
>> but I am puzzled by the const void *a. If this function
>> does what I think it does,
>
> Did you read or watch Princess Bride?
Eh?
>> the target of the pointer is altered.
>
> Well, `a' points to the start of array data, whereas what I
> (perhaps incorrectly) call its metadata is located at a
> negative offset, is indeed changed by the function, but is
> not literally pointed to by `a'. The array data may be
> reallocated as well, but the value of `*a' (with propor
> cast) will still be the first element of the array. Or
> should I say it will be changed because `a' will be
> pointing, in general, to an object of a different size and
> at a different address, albeit with the same initial
> contents?
The other way to look at it is to ask if it makes sense for a
user-written function, which is passed a pointer to a const void *a, to
call setlen. Alternatively, when reviewing code, I would assume that
such a function will have made no changes to any data associated with
the array object:
int user_calculation(const void *);
...
int result = user_calculation(array);
// Here, I would assume here that any data about 'array' obtained
// before this call is still valid, including the length.
...
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-23 19:10 +0300 |
| Message-ID | <20230923191049.30910ae1ec289b13dd6abd0a@gmail.moc> |
| In reply to | #175889 |
Ben Bacarisse to Anton Shepelev: > > Ben Bacarisse: > > > > > If this function does what I think it does, > > > > Did you read or watch Princess Bride? > > Eh? I couldn't help a refence to Princess Bride -- a fairy tale by William Goldman, which has a similar phrase line both in the book and movie: https://www.youtube.com/watch?v=dTRKCXC0JFg -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-17 17:17 -0700 |
| Message-ID | <86a5tkmj1b.fsf@linuxsc.com> |
| In reply to | #175828 |
Anton Shepelev <anton.txt@gmail.moc> writes:
> This is my function for setting the length of a dynamic
> array:
>
> void* a_setlen( void * a, unsigned len )
> { unsigned newcap;
> struct meta_t *m ;
>
> m = META ( a );
> m = setlen( m, len );
> if( m != NULL ) a = DATA( m );
> else a = NULL ;
> return a;
> }
>
> To allow for a potential reallocation, it returns an updated
> pointer to the array. Although it is small, and therefore
> easily understandable at a glance as is, I am taught and
> told that it smells bad, because of the reuse an input
> variable to store the new value to be returned. [...]
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;
}
Having the function parameters be const I would say is just
personal preference. With a function this short it doesn't
make much difference one way or the other.
The choice between 'void *a' and 'const void *a' has more
substance. If the memory pointed to by 'a' might be written by
this function (eg, in the call to setlen()) then 'const' should
certainly not be used. If the memory pointed to by 'a' will
definitly _not_ be written by this function, then my inclination
is to say 'const' should be used if (and maybe only if) it is
important to express that property. To say that another way, if
it's important for a caller to know that *a will not be modified
then 'const void *a' is appropriate, but if *a not being modified
is just a happenstance of how the code is written then my vote
would be to leave the const off.
I'm sure other people have some other opinions as to what is most
appropriate here. I am expressing a personal view and also some
of the reasoning behind it. I feel strongly that the best choice
in such cases is not just "always yes" or "always no".
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2023-09-18 11:53 +0300 |
| Message-ID | <20230918115357.0c06b3c4225a6c33bb3244dc@g{oogle}mail.com> |
| In reply to | #175832 |
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.
2. I consider nested calls a bit less readable than
sequential, alghough I do not alwasy avoid them.
3. Sequential calls let me insert ad-hoc debugging code
at the right points, e.g. between the invocations of
META() and setlen() above.
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 have snipped your comments about `const', but not without
having perused them.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web