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 | 15 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 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-27 03:21 +0000 |
| Message-ID | <20230926201809.34@kylheku.com> |
| In reply to | #176504 |
On 2023-09-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Adding it as _Elseif would IMHO be too ugly. Adding a new keyword > always risks breaking existing code, but C23 is already adding bool, > false, and true. One advantage might be that in LALR(1) parsing, "_Elseif" is a single symbol, consuming only one lookahead position, whereas "else if" is two tokens. If we are at else, and the next token is if, that's our lookeahead; we don't see past it. Whereas if wee are at _Elseif, we have whatever token follows as lookahead. I can't think of what situations that would benefit; i.e. what could be parsed that is not parseable now. -- 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-26 20:56 -0700 |
| Message-ID | <87pm24s20a.fsf@nosuchdomain.example.com> |
| In reply to | #176507 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-09-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Adding it as _Elseif would IMHO be too ugly. Adding a new keyword
>> always risks breaking existing code, but C23 is already adding bool,
>> false, and true.
>
> One advantage might be that in LALR(1) parsing, "_Elseif" is a
> single symbol, consuming only one lookahead position, whereas "else if"
> is two tokens. If we are at else, and the next token is if, that's our
> lookeahead; we don't see past it. Whereas if wee are at _Elseif,
> we have whatever token follows as lookahead.
>
> I can't think of what situations that would benefit; i.e. what could
> be parsed that is not parseable now.
Nor can I -- and if I could, I'd probably try to avoid writing code like
that.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-27 10:36 +0100 |
| Message-ID | <uf0t27$3149p$1@dont-email.me> |
| In reply to | #176504 |
On 27/09/2023 03:43, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I wonder how big a deal it would have been to introduce an actual
>> 'else-if' token? I expect it would look something like _Elseif; just
>> using a the hypenated 'else-if' would be better!
>
> A hyphenated keyword?
It would be three consecutive tokens: else, -, if, treated as though
there was a dedicated 'elseif' keyword. The advantage is that it
requires no new keyword.
> In various languages, I've seen "elif", "elsif", and "elseif".
> I'd be fine with any of those.
>
> But though I think it would have been nice to add such a keyword from
> the beginning, I'm not convinced it would be worth doing now. It's
> already perfectly possible to write long if/else chains in C:
>
> if (...) {
> ...
> }
> else if (...) {
> ...
> }
> else if (...) {
> ...
> }
> else {
> ...
> }
> (I know some people prefer to put the else on the same line as the {.
> That's not really the point.)
> Even though the indentation doesn't strictly reflect the grammar, it's a
> common enough idiom that that doesn't bother me.
It bothers /me/ because it's not pure. Because, if you write translation
rules, the nested nature of the chain is still there.
Both 'else if' and 'else { if' sequences are encountered in source code.
Because sometimes 'else' is followed by one statement, sometimes by
more, or you want the possibility that the one statement can be expanded
to more, or temporarily commented out.
You get that flexibility by having a strict rule that an 'if' statement
always looks like one of these:
if (cond) {...}
if (cond) {...} else {...}
and not for example like this:
if (cond) {...} else if (cond2) {...}
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-27 03:17 +0000 |
| Message-ID | <20230926200352.419@kylheku.com> |
| In reply to | #176502 |
On 2023-09-27, Bart <bc@freeuk.com> wrote:
> On 27/09/2023 00:05, Kaz Kylheku wrote:
>> How you make it vertical is via cond
>>
>> (cond
>> (test-1 stat-1)
>> (test-2 stat-2)
>> (test-3 stat-3)
>> (test-4 stat-4)
>> (t stat-5))
>
>
> Yes this looks like the 'case-when' statement I posted a day or two ago.
> If I rename 'case' to 'cond', and 'else' to 't', then it's almost the
> same other than the style of syntax.
>
> But this is yet another solution that doesn't exist in the main C language.
Yes; the multi-conditional statement is simulated by nested ifs.
> I wonder how big a deal it would have been to introduce an actual
> 'else-if' token? I expect it would look something like _Elseif; just
> using a the hypenated 'else-if' would be better!
You can get something like it using the preprocessor:
#define elif else if
The paradigm of "elif" is less flexible; since the lone else
combines with statements other than if as I showed in other posts:
if (this) {
x = 42;
} else while (i--) {
foo(j++);
}
A C implementation is free to recognize the abstract syntax tree
pattern:
if (E1) S1
else if (E2) S2
...
else if (EN) SN
else SF
and rewrite it into a single abstract tree node implementing
an equivalent internal case statement. That form could facilitate
certain analyses, like turning case into a switch, because that AST node
would have the clauses as children at the same level. E.g. answering
the question whether all the Ei expressions are constant would be a
simple iteration.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 16:46 +0200 |
| Message-ID | <uf1f8f$34mmt$1@dont-email.me> |
| In reply to | #176466 |
On 26/09/2023 19:53, Anton Shepelev wrote:
> David Brown to Anton Shepelev:
>
>>> Modern languages with multiple returns or tuples provide
>>> a partial solution, another being to unify error info
>>> with the result of successful execution in dynamic
>>> languages or ones with templates (to save the declaring
>>> a combined TResult type for every function). But then,
>>> I loose the whole pupose of an error flag -- the ability
>>> to invoke funtions inside an `if' statement.
>>
>> You realise that in C you can return structs, and thus
>> include status returns as well as value returns in one
>> item?
>
> I do, which is why I wrote about defining a
> <func_name>TResult type for /every/ function.
You don't need a separate type for each function.
> If, on the
> other hand, I define TResult to contain only error
> information and the success flag, I save a single parameter
> compared to returning the success flag and error info
> separately.
>
>> Still, why are you talking about modern languages and
>> object oriented programming when you insist on using a
>> language outdated a generation ago?
>
> Because C lacks those new features and I am spared the
> pressure to use them in my code :-) Seriously, I see nothing
> bad in considering alternative approaches to get out of the
> box, so to say... I do not think C is outdated a generation
> ago, and even the new standards have far from changed it
> beyond recognition. It is basically the same language.
Thinking about alternatives is always a good idea.
No, C is not outdated (though there are better choices for many of the
programming tasks that used to be done in C). But C90 /is/ outdated,
and has been for a very long time.
>
>>> Linus 8-chareater-tab Torvalds was IMHO right when he
>>> decreed that a function shall not have more then three
>>> levels of nesting, his enourmous tab serving as a dumb,
>>> primitive, mechanical, and ugly means of enforsing this
>>> decree.
>>
>> No, Linus was wrong - as he is on many things. (He's
>> right on many things too, of course.) We are not using
>> typewriters, we are not using 80x25 character displays,
>> and we do not need to have pointless limitations.
>
> They are not pointless. 80 characters is a generous the
> upper limit of a compfortable line width, most typographical
> manuals suggesting lower lengths, and I did not refer to the
> 25-line limit anywhere. My functions are frequently longer.
No, 80 characters is not a comfortable line width limit. It is very
artificial, and limits the use of longer identifiers or occasional
naturally longer lines. Remember, line width limits in programming are
not remotely the same as letter counts per line in prose text.
>
>> I don't advocate for deeply nested or overly complex
>> functions, of course - I advocate for clear code with
>> immediately obvious blocks indicated by braces /and/
>> indents. And if clear code requires more than 3 levels of
>> nesting, use that.
>
> In my opinion, up to three levels are easy to perceive, and
> then it becomes harder epxonentially: four levels is
> tolerable and five is a mess.
>
In reality, it depends on the code and the structure, as well as the
familiarity for the programmer. There's no doubt that deeper nesting
gets harder to follow, all other things being equal. But all other
things are often /not/ equal. Good indentation is hugely easier to
interpret than flat unindented code, or strange "outdented" styles. If
there is a clear pattern to a piece of code, then deeply nested code
will be perfectly comprehensible.
/Most/ code probably needs no more than three levels of indentation (in
addition to the indentation for the function body). But that follows
from the principle of avoiding doing too much in one function, rather
than any fixed rule for indentation limits.
All you achieve by putting arbitrary limits on these things is that the
occasions where longer lines, or deeper nesting, or bigger functions
would result in clearer code, now have to be artificially divided up in
less clear ways. It doesn't help for most code, which will already be
well within whatever limits you pick, but it means that less common code
is worse off.
>>> For an example, and the standard if-else-if-else...
>>> chain is in fact a variant of a switch, and a switch has
>>> the
>>
>> Not in C.
>
> Yes, I meant the broader condept of switch as a table of
> tests and corresponding statements, with perhaps a fallback
> (default) entry. The point is that the sturcture of switch
> is a table with two columns (see below).
>
>>> if( test_1 ) {
>>> stat_1 } else {
>>> if( test_2 ) {
>>> stat_2 } else {
>>> if( test_3 ) {
>>> stat_3 } else {
>>
>> I have never seen if-else chains formatted that way - it
>> is clearly incorrect indentation.
>
> It is technically /the one true/ correct indentation,
> because each level of nesting has its own indent.
Again - I have never seen if-else if-else chains formatted that way. If
you think it is "technically" following the rules, then you have
misunderstood the rules, or whoever gave you the rules (perhaps me)
oversimplified them. The point of style rules is to give clear and
consistent visual formatting that minimises the risk of misunderstanding
or making errors - they are not designed to give simplistic but absolute
rules that result in incomprehensible monstrosities.
The additional rule here can be thought of as treating "else if" as
though it were an "elseif" keyword.
>
>> if (test1) {
>> stat_1;
>> } else if (test2) {
>> stat_2;
>> } else if (test3) {
>> stat_3;
>> } else {
>> ...
>> }
>
> Now, you have recoginised that although syntatically it is a
> deeply nested unblananced tree, semantically it is a linear
> structure, and therefore you flattened it, so that the
> nesting level is no longer equal to the indent. Does a dumb
> pretty-printer understand semantics? Do coding standards
> care about semantics?
Of course pretty-printers take semantics into account. Except for a few
points (such as line continuation, and single-line comments), all white
space is syntactically equivalent to a single space character in C, and
most such spaces have no syntactic meaning at all. "Pretty printing" is
all about making the visual appearance match the semantics of the code,
while keeping the syntax unchanged.
>
>>> if( test_1 ) stat_1;
>>> else if( test_2 ) stat_2;
>>> else if( test_3 ) stat_3;
>>>
>>> It shorter, clearer, and better structured, because the
>>> programmer has formatted the code according its intent.
>>> Observe also the indent of the first `if' to have it
>>> aligned with the other entries of the table.
>>
>> That's a strawman argument, because no one would ever
>> write an if-else chain the way you first suggested.
>
To be clear here - your comparison of your choice of formatting with
your unbalanced tree version is a strawman argument, because no one
would ever write the unbalanced tree version. A comparison to the
linear structure that I gave would not be a strawman argument, because
it is the form that many people use in real code.
> No, what /you/ say after `because' is a strawman argument
> becase it appeals to external circumstances (the number of
> followers) rather than criticises the formatting itself. I
> will try to explain my formatting again: the structure of
> that control statement is a table with two columns and three
> rows. A careful programmer, having respect for the reader,
> will therefore take advantage of the 2-dimensional nature of
> text and format it in a 2x3 grid, aligning the correspondent
> parts together:
> test_1 stat_1
> test_2 stat_2
> test_3 stat_3
>
> It is only meet also to alignt the correspondent keywords,
> as I have done above. This is the only way to express the
> programmer's intent in the formatting. Curly braces would
> be redundant, because the structure is sufficiently
> transparent not to require them, but you can add them
> anyway:
> if( test_1 ) { stat_1 ; }
> else if( test_02 ) { stat_02 ; }
> else if( test_003 ) { stat_003; }
>
> I have introduced indentifiers of varying length to show the
> correct horisontal alignment of closing parentheses, curly
> braces, and semicolons.
>
I appreciate your argument about this being a "grid" structure. But I
disagree about it being of much use in practice. (There can be
occasions where an unusual code layout can make things clearer because
of particular patterns.) The reality of conditionals and corresponding
statements is that they will rarely be close enough to similar lengths
to make such a layout practical. Once you have written "if
(current_count < min_acceptable_count)", your code is mostly empty
horizontal spaces taking focus away from what you are actually doing.
(And you'd quickly break your 80 character limit.)
Code sections of significant length that might fit your pattern could
often be better expressed as switch statements, or perhaps using a real
table of some sort. But I can agree that /sometimes/ there might be
such regularity over so many cases that it is worth having an odd layout
like this.
> You say that your version above
>
>> is clearer than yours, and far more maintainable.
>
> I outright deny that it is any clearer. It is certainly
> messier and less structured, which any non-programmer, or a
> programmer without professional bias due to experience with
> curly languages, should confirm. Show them our styles
> side-by-side:
>
> Format I | Format II
> |
> if (test1) { | if( test_1 ) stat_1 ;
> stat_1; | else if( test_2 ) stat_2 ;
> } else if (test2) { | else if( test_3 ) stat_3 ;
> stat_2; | else stat_def;
> } else if (test3) { |
> stat_3; |
> } else { |
> stat_def; |
> } |
>
I don't write code for viewing by people without significant experience
in curly-bracket languages. (Well, I do sometimes - but that's when I'm
writing code in a language that does not use curly brackets.) How could
someone unfamiliar with C judge the clarity of C code as read by C
programmers? Or are you basing this all on some highly personal and
subjective idea of visual aesthetics?
> As to maintainability, it depends. My version is suitable
> for small, ideally single, statements, whereas yours is more
> universal and works better with large, compund ones.
My version is equally good for small tests and single statements.
> In my
> own practice, however, I never need an if-else chain with
> large statements, for some reason. If I should suddently
> need to introduce long statements into my if-else chain, I
> will then rewrited it differently, but not before. The
> problem of universal one-for-all formatting rules is that
> they are not optimised to the situation at hand, cf. my
> three versions of an shortened if-else statement, each for
> its own purpose.
>
>> And any coding standard with a care for safety, security
>> or reliability, (such as MISRA or JSF-AV mentioned in this
>> thread) will insist on the braces here.
>
> Why is my version unsafe, insecure, and unreliable? What
> kind of error does it invite? My opinion is that, as long
> as the grahica tabular alignment is kept in place, human
> errors are very unlikely.
The kind of errors made as a result of poor brace style are
misinterpretations about semantic nesting, errors when changing existing
code that now need braces where braces were missing, and unexpected
multiple statements due to macros.
I don't think your example here is very likely to be misinterpreted, but
it is harder to read because the conditionally executed statements are
not as visually differentiated, and because the extra horizontal space
makes the code flow harder to follow. (It reads like long pauses in the
middle of the flow.) Again, there could be occasional types of code
where it gives a useful pattern that makes code clearer, but it is not
common IME.
If someone wants to change your code by adding an additional statement
to one of the conditionals, braces must be added - spoiling the pattern,
and completely negating all benefits of the layout. It would not be
hard for them to get it wrong and forget about the braces. It is even
worse when you have macros in the mix - sometimes macros are more than
one statement.
Generally, however, the biggest issue I see is that your layout is so
fragile. I asked you before if you use any kind of source code or
version control system. I suspect not. Imagine you have a 10 line set
of such "if" statements. There is a change needed to one of the
conditionals that increases the maximum length of the conditionals. Now
instead of a one-line change - and a one line patch, one line code
review - you've got to change every line of the beast to add extra
spaces. The commit is now a large lump. And if there is one thing
development teams and code reviewers hate, it is wads of pointlessly
changed lines hiding the real changes in white space modifications.
And with any more serious changes - multiple statements for one
conditional, a significantly bigger test in one case, a comment needed
for a case - and the whole thing collapses.
>
>>> Coding standards rarery (if ever) take these semantical
>>> (intent) and perceptinve (table) considerations into
>>> accout, whereas automatic linters or pretty-printers
>>> supply the necessary technology to implement this
>>> Nazism.
>>
>> I have no idea what you are trying to say there.
>
> That quotation contain two parts. The first one states that
> coding standards require a uniform formatting style based on
> the syntax of the language, ignoring the fact that the same
> syntax may express different semantics.
No, they don't.
> For example, a
> syntatically deeply nested if-else statement may be written
> with deep indentaiton and without (as you have done above),
> depending on the intent of the programmer it expresses, that
> is whether it is sematically deeply nested. The enforcement
> of a uniform formatting regardless of intent makes code less
> readable.
>
Coding standards are rarely as draconian as you seem to imagine. And
pretty much any coding standard allows exceptions if suitably justified.
> The second part refers to my previous observation that
> coding standards are often enforced by automatic tools,
> which (unaware of sematics and the programmer's intent),
> format everything accroding to the same mechanical (syntax-
> based) rules, effectively destroying any effort of the
> programmer to increase readability by emphasizing code
> structure via semantic formatting.
>
People coding to documented standards do not do so by writing code in
some random style and then running it through a "formatter" to fit the
style. They write the code in the required style - perhaps using an
editor or IDE that provides some convenience (such as indentations
matching brace style), but which can be easily overridden.
Some aspects of coding style may be checked by tools - and I think that
is a very good thing (we all make mistakes). But you seem to be
imagining a world where programmers are at the mercy of automated tools
that blindly follow the arbitrary rules set by dominating by ignorant
project managers. Maybe such development groups do exist, but I don't
believe they are common practice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-25 21:16 +0200 |
| Message-ID | <uesm9l$22hlu$1@dont-email.me> |
| In reply to | #176376 |
On 25/09/2023 19:56, Bart wrote: > On 25/09/2023 14:40, David Brown wrote: >> On 25/09/2023 12:51, Bart wrote: > >>> suppose I define a typedef say at module scope to be shared by >>> functions 35, 62 and 78 of 100 functions in that module. >>> >>> Where should I place that typedef: before the definition of function >>> 1, or immediately before function 35 since that is where it is first >>> used? >>> >> >> That's a stupid question. Don't have 100 functions in your module. > > Huh? I didn't realise that was that controversial. I don't actually know > how many functions I have per module, I've never counted! > What is "too big" will, of course, vary significantly - there is no fixed limit. But if you are having difficulty figuring out where to put things in the file and be able to find them easily, it's too big. If you want clear and easily navigable code, don't make your files too big. It's as simple as that.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-29 00:38 +0300 |
| Message-ID | <20230929003818.0f2c31ab18d1a86c8bcb181e@gmail.moc> |
| In reply to | #176338 |
David Brown:
> Wirth's languages tended to have strong separation of data
> and code. But remember, the focus of his languages were
> on two things - being good for teaching and learning, and
> being simple to implement (when optimisation is not
> important). C does not fit into either category. Nor do
> other major languages used for "real" programming.
Even so, I think Wirth considered these noble goals as
/conductive/ to the production use of his languages, rather
than contrary to it, as do his critics.
> (Of course there are "real" programs written in Pascal -
> but for the most part, you'll see Wirth's languages in
> academic institutions, not in the software industry).
Free market evaluates things not according to their
intrinsic value, but always through the ultimate criterium
of profit, where sponsorship, adverisment, and lobbism play
an important role -- factors sufficiently suppressed in the
academia.
> Also remember that Wirth wrote that (and languages like
> Pascal) some 40-50 years ago. We've learned a lot since
> then, and developed better coding techniques over time.
Yes, but very often at the expense of a rapid growth of the
complexity in the later programming languages, think C++!
> Wirth's most modern language, Oberon, is object oriented -
> data and code are much more integrated and mixed in such
> code.
They are, but not so tightly as in typical OOP of our day.
Instead of complete class inheritance, Wirth introduced two
simple facilities: extension of record types and the IS
operator. His methods are still pointers to normal
procedures and functions exsiting outside record types and
executed in their natural context, that is without an
implied `this' or `self' parameter.
> I can see that putting the variables at the start of the
> function lets you make a list like that. I cannot,
> however, see any advantage of having such a list.
One reason is that finding the type and annotaition to a
variable is simplified. With interleaved combined
declarations and initialisations, one has to scan through
the entire wall of text backwards, and that the typical
intialisaion does not /start/ with the variable name only
aggravates the situation: examining the start of every line
is not enough.
> Local variables are temporary - they are just there to
> hold intermediary results and give convenient names to
> things so that it's easier to see what is going on.
/Just/ is understatement. Their role is very important.
> A list of variables does not aid understanding of a
> function - rather, it detracts from it because you are
> splitting the information (how the variable is declared,
> and how it is used) into two separate parts.
You can see it that way, but the contrary extreme of mixing
everything into one homogenious mess does not help either.
Separate declarations introduce some order and make the
operational code more regular, by having all the assignments
start with the name of the variable.
> > Upon encountering a new variable, the reader can glance
> > at the top of function to find its type and desctiption,
> > whereas intermixed style is requires scanning the entire
> > text, unless, of course, you count IDE helper tools,
> > which I do not. Code should read smooth off a printed
> > page.
>
> With your style, the reader encountering a new variable
> has to deal with two wildly separate parts of the text -
> the definition at the start of the function, and the use
> of the variable in the code. It is particular bad for
> large functions or when you have a small screen or window
> (this can be the case when you are debugging, for
> example), and you have to scroll around.
I partially disagree. My approach is indeed particularly
bad for large functions on a small screen, but at the same
time I find it particulartly good for small functions, and
quite good for medium ones.
> With my style, everything is there clearly in one spot.
Yes -- because of better spacial cohesion. "Everything" is
an exagerration, however. Variables having different
lifespans, some may be used from way up above.
> No scanning or searching is needed - it's all there on the
> same line or two.
Not at all, because /any/ variable may have been declared
and initialised /anywhere/ above. It may be two lines, five
lines, or even fifteen lines up.
> > Interleaved initialisation makes the code visually
> > ragged and uneven -- to my taste. The declarations
> > "data" it works with are scatterd all over the place
>
> I write code, I don't draw pictures. The aim is to make
> things clear to human programmers reading the code, not to
> match the aesthetic tastes of art critics in a gallery.
> The visual appearance of code matters if - and only if -
> it affects the readability.
Each thing has its own beauty, so that beautiful code is as
admirable as a Turner landscape. Code beauty is of course
different, for its purpose is not only to evoke pleasure in
the observer, but neither is the that of the typography of
technical documents or literary works! It is the same kind
of beauty to which Tufte refers in the title of his book
"Beautiful evidence" -- ergonomic, perceptively optimised.
You are right on the spot in that code is not a picture, yet
it is of two-dimensional structure, and to use both
dimensions to advatage is only natural, whence indentation,
horisontal alignment, and the table-like formatting that I
propose for everything that is conceptually a table, even if
syntatically it is a series of function falls:
register_menu( "Start a new game", on_start );
register_menu( "Settings" , on_settings );
register_menu( "Exit" , on_exit );
> > When maintaining a unified section with declarations
> > becomes uncomfortable -- it is a natural signal the
> > function should be split or otherwise simplified.
>
> That is always the case for functions, no matter the style
> used.
With your method, adding new code paragrahs is very cheap
regardless of function size, because you do not have to go
all they way up to declare a new variable.
> The reality, however, is often different. Many functions
> start off small, but grow bigger than desirable as the
> code evolves. Your style gets more and more tedious,
> uncomfortable, and error-prone, to a much greater extent
> than defining local variables as an when they are needed.
In this wise my style signals to the programmer that the
time has come to split the function up.
> This is exasperated by C90 styles from the days of weaker
> compilers and no "inline" functions, when people wrote
> longer functions and hideous function-like macros because
> splitting up functions made code slower.
"exasperated by C90" ?-)
Even back then the entire programming style cannot have been
dictated by reasons of performance. The smart programmer
always designes and writes for the human, optimising only
the bottlenecks he finds, which typically constitute a minor
part of the program.
> Extensive use of "goto" is a strong indicator of poorly
> structured code, functions that are far too long, or a
> programmer doing "micro-optimisations" that are better
> left to the compiler. (There are some types of code for
> which "goto" makes things clearer, but I think they are
> rare.)
I believe that in many common situaions goto's can be used
/in/tensively and to an advantage in code structure and
readability, even as `break' and `continue' statements.
Incidentally, you did not comment on the article about
Gotophobia[1] mentioned here on the 1st of March.
> And I would say that defining variables at the top of the
> function is the worst choice you could have if you use
> "goto" often. It is better to consider labelled parts of
> the function as "sub-functions", each with their own local
> variables defined and initialised within their local
> areas.
Sometimes I do view /certain/ labelled secitons as sub-
functons. Even if the C stanards and the compiler will let
me jump over variable initialisations, I myself feel chary
of doing so because I my mentail model of code execution
does not empbrace it. I will rather turn such a sub-
function into a true function and invoke it...
> That's the focus here - the /human/ knows that the
> variable is always valid. They don't have to wonder if it
> has been set yet, no matter where they look in the code.
The compiler will detect the use of unininialised/undeclared
variables in both our styles. If the human does not rely in
this on the compiler, then he must determine the question by
examining context.
Manually to determine whether a varible is initialised at a
certain line, the programmer must scan the code from that
line upwards till he find the initialisation or an
assignment (in your style), or till he find an assignment
(in my style). There is not much difference, except that in
your case the occurence of either of two possible statements
is being sought. I have a hunch that I misunderstood this
argument of yours, though.
> From what you've written so far, I don't see any
> significant features of your style that could not be
> accomplished equally well by comments. Why not write
> (formatted however you prefer) :
> // int sum_sq - holds the sum of the squares
>
> at the top of the function, and then
>
> const int sum_sq = x * x + y * y;
>
> in the code?
This is very tedious to maintain. It is prone to errors
because the compiler does not check comments. Less
importantly, jumping to definition from IDE will not bring
me to where need.
> Or even use doxygen format (with "\var")?
You suggest I use the Doxygen format without Doxygen itself?
Well I will tell you again that this kind of duplication
gives me a headache. I could, however, try this at work on
a larger scale, and in a different language, to document the
interface functions of a module. But then, when a
programmer jumps to the function definition via the IDE
command, the documentaion is nowhere in sight...
> You only need to document the important local variables
> that help the reader understand the code, not the little
> ones whose use is obvious.
Right.
> > But I prefer to optimise for reading rather than for
> > writing.
>
> So do I - that's why I avoid your style of coding.
:-)
> I realise writing style is often very personal - but
> remember that /reading/ is much less personal. /You/ may
> find it easier to read ancient Greek than English, but
> most programmers do not.
To nitpick at your analogy a bit, I will observe that
regardless of language, the rules of rhetorics are the same
for all literate humans!
> Similarly, "optimising for reading" must concern itself
> with /other/ programmers. Imagine someone who learned C a
> mere 20 years ago and reads everything on screens, rather
> than someone who sees C and fanfold paper printouts as a
> step up from FORTRAN and punched cards.
Man's perceptive faculties and cognitive abilities have not
changed since then. If code formatting and layout
emphasizes its structure and the author's intend behind it,
it is as good now as it was then. Whatever code patterns
are conceptually tabular must be formmated that way. Now I
may have a 80x50 screen instead of the standard 80x25 one,
which is an improvement, but I will not have a wider line
length.
> Even when I had to use C90 I preferred to be able to
> declare variables inside code blocks. I rarely made
> artificial blocks just for variable declarations, but used
> natural blocks for conditionals, loops, etc.
I remember them from my university days. I even used them,
by declaring (yet not initialising) varialbes at the start
of those natural blocks.
> > Probably. In the case of `newcap', I thought GCC's
> > -Wall included the warning about unused variables (and I
> > use -WError), but it does not.
>
> It does warn about unused variables - there must be some
> other reason why you did not get a warning.
It should have failed to compile, actually, because of
-WError. Now I see that I had rewritten my makefile at some
point, and forgot about those options.
> But do not use compiler warnings as a crutch for poor
> development practices and coding styles.
Because I write for readability, this minor problem is of
secondary priority to me. You must agree that writing
programs in a bare editor without a compiler or anoher tool
to check the syntax is /so much/ harder, and the fact that
you use (if you do) a compiler, a debugger, and an IDE that
seamslessly interacts with them throghtout the programming
process is not an instance of a crutch for poor development
practices...
> They prevent accidents (we all make mistakes sometimes).
> They are a complement and addition to other practices that
> encourage good coding - they don't replace good design,
> good code layout, re-reading your own code, etc.
Yes, and the same applies to IDE, test suites, and version-
control systems. They should not force a coding style upon
you, but rather work with yours. The idea of marking public
functions in a module instead of listing them in a seaprate
section (the interface part) or file (the header file in C)
has been made possible because of autocompletion and code
navigation facilities in IDEs, whithout which the compact
description of a module's interface at the start of a Modula
unit or in a C header file (if it is a nice one!) is
indispensable. That, I think, is an instance of development
tools affecting coding style. Anoher such instance is the
ability to order functions arbitrarily, thanks to multipass
compilers.
> > > * Making new local variables becomes "cheaper" in
> > > terms of writing the code, and for people reading
> > > and understanding the code.
> >
> > Controverisal for me: cheaper in the sense you give, but
> > dearer me as reader.
>
> Local variables are not merely "cheap" from a compilation
> viewpoint - they are in most cases free. So whether you
> are writing code where efficiency is not top priority
> (most code), or writing efficiency-critical code, extra
> local variables are free. Thus there is nothing to stop
> you using them to make code clearer.
I start by writing readable code without any concern for
micro-optimisation. If the return value of some function is
better stored in a separate variable, rather then reusing an
exising one /accidentally/ of the same type, of course I
introduce such a variable. Since the funciton in question
effectively replaces one instance of an array with another,
I thought it OK to reuse the input variable to store the new
array being returned.
> > I agree that in general, using variables permanently to
> > store the value they are first assigned makes for more
> > readable and less error-prone code. I myself often do
> > it at work, albeit in a language without a concept
> > `const'. As the function grows longer, the advantages
> > of combined in- place declaration and initialisation
> > become more apparent, and start to outweigh the
> > advantages of the alternative approach (as I see them).
>
> If you agree with that, what possible advantages do you
> see from declaring these "permanent" variables at the
> start of the function?
I have been trying to explain my reasons for some time
now...
> All you are doing is introducing a needless separation,
> forcing readers to look in two places in the code to see
> what is happening (one for the type, one for the value.
Such a separation is not necessarity needless, cf.
footnotes, endnotes, tables of contents, and glossaries in
books. They are not inline to create separation and improve
readabilty.
> Yes, assignment in an imperative language is different
> from equality in mathematics. But when I can write my
> statements of action in a way that also makes them
> statements of fact, the result is clearer code less open
> to misinterpretation by readers or mistakes by the writer
> (or maintainers).
I'd say it is a differnt way of thinking about execution,
which is further from the C execution model than form that
of some functional language. C is not afraid of changing
state, and neither should be the C programmer.
> > if( m != NULL ) a = DATA( m );
> > else a = NULL ;
>
> It shouts - that's due to use of all-caps macro names. It
> reads "NULL", "DATA", "NULL", and then you have to look
> closely to see the rest of it.
NULL is a standard macro, I cannot change it. My own macro
is uppercase to match the style and to distinguish it form a
function. Granted, I can get rid of uppercase identifiers
by redefining NULL as null, by defining my own macros in
lowercase with the `m' suffix or prefix. Would you like it
better?
> It fails to show the structure of the "if" - there are no
> blocks, and no indentation to make it all obvious to the
> reader.
And I am of the opposte opintion -- that the sturcture is
very clear from the tabular arrangement of the elements:
if -- then-clause
else -- else-clause
> Maintenance is harder (imagine adding more statements to
> the conditional parts),
Yes, but I win in readabitliy compared to the more universal
yet clumsier forms. If the branches change in a way that I
cannot keep this layout, I will reformat in a more suitable
manner.
> and the use of macros within unblocked conditional
> statements compounds this.
I beg your pardon, but what is the exact problem with using
macros as above?
> It adds unhelpful extra spacing, more reminiscent of
> FORTRAN fixed column layouts than modern coding.
You call it unhelpful, I call it the necessary alignment to
emphasise the structure. We seem to be going in rounds
about this particular point. I don't know about FORTRAN
fixed-column layours, but I know that code should be written
in a fixed-width font (to the detriment of Niklaus Wirth
with his proportial coding), especially to allow for such
alignment.
> It adds an unhelpful extra comparison inside the
> conditional - it takes very little familiarity with C to
> know that "if (m)", where "m" is a pointer, checks for
> non-null pointers.
Then it is not an extra comparison, but rather a comparison
stated explicitly. I find explicit comparisons more
readable (because part of the universal mathematical
symbolism), and only allow boolean (or flag-like)
expressions inside the if statement wihout a comparison
operator, because comparing a value to to true or false is a
real tautology.
> Putting that in explicitly adds nothing, but leaves
> readers wondering why.
Because saying "if the file pointer is null" is good natural
language, and "if the file pointer" is bad and unnatural,
even in math. Not all constructions C allows are readable.
> Do not mistake your own familiarity with a particular
> layout as meaning it is "precise" or "clean". (I know
> everyone, including me at least as much as anyone else,
> /does/ make that mistake.)
Indeed, it is often a surprise to find out that not everyone
in the world thinks as you do...
But I explain why my layout is readable by appealing to
general logic, regardless of who is accustomed to what. One
may become accustomed to bad things and well as to good
ones. I started programming in curly languages in the K&R
style, and slowly evolved mine from there.
By the way, Paul Edwards of PDOS, liberally uses horisontal
alingment, if I do not misremember.
> > if( short_condition() ) long_long_long_long_expression ();
> > else very_long_long_long_long_expression();
> >
> > if( long_long_long_long_long_long_condition() )
> > super_long_long_long_long_long_long_long_long_expression() ; else
> > ultra_long_long_long_long_long_long_long_long_long_expression();
>
> I also find your horizontal spacing choices put all
> the space in the wrong places. It's like suddenly
> finding extra spaces, or crushedupwords withnospaces in writing.
Elsewhere you wrote (or was it Tim?) that code is not prose
text, yet you judge my code by the standards of prose text.
Your parody of my code in prose reads terrible, and I should
hate to read a book typeset that way. But code is not
prose, it is stuctured to a much higher degree, for which
reason you have lines of code and indentation. Horisontal
alignment is just another means of reflecting that
structure.
> The more cognitive effort it takes to interpret the layout
> of the code, the less the reader has left to understand
> the /meaning/ of the code.
On the contrary -- layout saves cognitive effort. For an
(thought) experiment, take any C program and replace all
whitespace compacts with a single space character, insert
the result into a word processor and render it in a
proportional font. That would be some unstructured
mess -- the opposite of what I do. It would require an
enormous coginitive effort to understand by reason of the
/absence/ of a structure-emphasizing layout.
From that extreme situaion, I conclude that the closer the
layout refects the structure of code, the more readable the
code is. If splitting code into logical lines and using
indentation is good for that, I see no reasons why
horisontal alignment isn't. It is another means of graphical
arranement of code.
> > > void * setlen(void * a, unsigned int len)
> > > {
> > > meta_t * m1 = META(a);
> > > meta_t * m2 = setlen(m1, len);
> > > if (m2) {
> > > return DATA(m); /* Ant: did you mean m2 ? */
> > > } else {
> > > return NULL;
> > > }
> > > }
> >
> > Several lines with but a curly brace on them -- seems
> > ugly to me.
>
> That's the way the language layout goes. If you don't
> like braces, you are never going to be happy with C !
(and the } else { line is offending!)
No, it is only the K&R layout that you defend, whereas there
are many alternatives, every one of which is my opinion
better (for readability) than this impudently named one true
style:
<https://en.wikipedia.org/wiki/Indentation_style>
> I follow the same pattern for Pascal code layout (with
> begin/end instead of braces, obviously).
You have occasion to write in Pascal proffesionally?
> The style I use is known as "The one true brace style".
> It is very simple - open braces occur only at the end of a
> line, and are followed by an indent level. Close braces
> occur only at the beginning of a line, and have an
> outdent. Everything is very simple, clear and consistent.
It is inconsistent in that the opening and closing braces
and misaligned and the opening brace of a function body is
on a line of its own.
> Do you use source code control systems (Git, svn, etc.)?
Yes, svn.
> A good layout like mine makes it hugely easier to work
> with these tools, and have your changes (especially small
> changes) show clearly where the workings of the code
> change rather than unhelpful changes to the layout.
I write for readers, not for writers, nor for `svn diff'.
Yes, sometimes I need to re-alingn lines that are otherwise
unchanged, and to deal with it in the diff output.
But if you care about this, then the Allman style is better
for you, because it lets you insert a line in the beginning
of a block without affecting the opening brace, which is
always on its own line.
> > Oh, but this is another penchant of mine -- to have a
> > single exit point from every function.
>
> That is a common rule. It is, IMHO, a mistake when taken
> too far. It is also usually a bad idea to have lots of
> returns scattered around a big function.
Yes, and some languages make it very hard to follow.
Python, for example, without a `goto' statement but with
enforced indentation that can't be fooled.
____________________
1. https://web.archive.org/web/20230226234720/https://blog.joren.ga/gotophobia-harmful
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-29 10:07 -0700 |
| Message-ID | <8734ywsyab.fsf@nosuchdomain.example.com> |
| In reply to | #176671 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> (C23 is not out yet, but you can use "#define nullptr (void*) 0" in
> anticipation.)
I think you mean:
#define nullptr ((void*)0)
or even:
#if __STDC_VERSION__ < 202311L
#define nullptr ((void*)0)
#endif
--
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-30 17:34 +0200 |
| Message-ID | <uf9f65$vbrl$2@dont-email.me> |
| In reply to | #176747 |
On 29/09/2023 19:07, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> (C23 is not out yet, but you can use "#define nullptr (void*) 0" in >> anticipation.) > > I think you mean: > #define nullptr ((void*)0) Yes, the extra parentheses are a good idea. (I don't think there are many good uses of "nullptr" where the extra parenthesis would make a difference, but it could be useful in turning some mistakes into compile-time errors rather than silent errors.) > or even: > #if __STDC_VERSION__ < 202311L > #define nullptr ((void*)0) > #endif > Sure.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-23 11:57 -0700 |
| Message-ID | <86msxck99x.fsf@linuxsc.com> |
| In reply to | #175882 |
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> 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.
I have reflected on these comments and also some of the responses
you have given to other posters. Here are some high-level
reactions (without specifics).
One: all of your preferences basically boil down to "this is
what I'm used to".
Two: you really need to learn new ways of thinking. You won't
see (I predict) the advantages of alternative approaches until
after you have assimilated them. If you don't make an effort to
try and embrace other approaches you'll be caught in a vicious
cycle.
Three: Why should you give any weight to my suggestions? Think
about this: I have been where you are. All of the things you're
saying are things I might have said earlier in my programming
experience. Fortunately I got some guidance from some very smart
people and was able to learn new ways of thinking about programs.
As an exercise try writing a_setlen() like this (and I mean
really try it, put the code in and get it to compile). Don't
complain about how awful it looks, I know it's different from
what you're used to.
void *
ATEM( struct meta_t *m ){
return m ? DATA( m ) : NULL;
}
void*
a_setlen( void *a, unsigned n ){
return ATEM( setlen( META( a ), n ) );
}
Needless to say 'ATEM' is 'META' spelled backwards. If you
think of a more suitable name feel free to use it, otherwise
exactly like this (with my usual caveat to ignore differences
in layout style).
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-24 00:07 +0300 |
| Message-ID | <20230924000740.2334b4ed1309a51f3eca26a9@gmail.moc> |
| In reply to | #176264 |
Tim Rentsch:
> One: all of your preferences basically boil down to "this
> is what I'm used to".
Well, I did not say that exactly. Nor did pick my style
from somebody else, but rather arrived at it thought
practice.
> Two: you really need to learn new ways of thinking. You
> won't see (I predict) the advantages of alternative
> approaches until after you have assimilated them.
Allright, I can /try/ alternative approaches in practice,
but /assimilating/ them in course of this trial seems very
hard!
> If you don't make an effort to try and embrace other
> approaches you'll be caught in a vicious cycle.
circle.
> Three: Why should you give any weight to my suggestions?
> Think about this: I have been where you are. All of the
> things you're saying are things I might have said earlier
> in my programming experience. Fortunately I got some
> guidance from some very smart people and was able to learn
> new ways of thinking about programs.
That is a good reason.
> As an exercise try writing a_setlen() like this (and I
> mean really try it, put the code in and get it to
> compile). Don't complain about how awful it looks, I know
> it's different from what you're used to.
>
> void *
> ATEM( struct meta_t *m ){
> return m ? DATA( m ) : NULL;
> }
>
> void*
> a_setlen( void *a, unsigned n ){
> return ATEM( setlen( META( a ), n ) );
> }
Coincidentally, I had already rewritten my code to something
similar in an attempt to generalise a repated parrten:
static void* oper_wrap( struct meta_t* m )
/* An operation wrapper, introduced as an attempt to generalise the */
/* repetitive logic of convering the metadata pointer to the array pointer */
/* and handling the error, a full-fledged lambda emulation via function */
/* pointer having been deemed an overhead: */
{ void *a;
if( m != NULL ) a = DATA( m );
else a = NULL ;
return a;
}
static void * setlen( struct meta_t *m, unsigned len )
/* Set the length of array [m] to [len]: */
{ unsigned newcap;
float factor;
if( len <= m->capacity ) goto Skip; /* no shrinking */
if( len > 1000000 ) factor = 1.19;
else if( len > 10000 ) factor = 1.41;
else factor = 2.00;
newcap = len * factor;
m = setcap( m, newcap );
if( m == NULL ) goto End;
Skip: m->length = len;
End : return m;
}
void* a_setlen( void * a, unsigned len )
{ return oper_wrap( setlen( META(a), len ) ); }
> Needless to say 'ATEM' is 'META' spelled backwards. If
> you think of a more suitable name feel free to use it,
> otherwise exactly like this (with my usual caveat to
> ignore differences in layout style).
Rewriting it your way from the above will be trivial, I will do
it.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-18 02:38 +0000 |
| Message-ID | <20230917171321.410@kylheku.com> |
| In reply to | #175828 |
On 2023-09-17, Anton Shepelev <anton.txt@gmail.moc> wrote:
> void* a_setlen( const void * const a, const unsigned len )
^^^^^ ^^^^^
These consts are not part of the interface. They make no difference to
the function type. The declaration of this function could be:
void* a_setlen( const void *a, unsigned len );
If this function potentially invalidates the original "a" object,
such that the caller should capture the returned pointer and
stop using the pointer "a", then "const void *" makes no sense.
--
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 | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2023-09-18 11:07 +0300 |
| Message-ID | <20230918110737.ac18c907afec14e235fe9766@g{oogle}mail.com> |
| In reply to | #175840 |
Kaz Kylheku: > The declaration of this function could be: > > void* a_setlen( const void *a, unsigned len ); > > If this function potentially invalidates the original "a" > object, such that the caller should capture the returned > pointer and stop using the pointer "a", then "const void > *" makes no sense. Yes, after calling: b = a_setlen( a, 55 ); `a' is no longer guaranteed to be point to a valid array, and `b' must be used thenceforward. This is exactly my case. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-18 15:24 +0000 |
| Message-ID | <20230918081739.303@kylheku.com> |
| In reply to | #175866 |
On 2023-09-18, Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Kaz Kylheku:
>
>> The declaration of this function could be:
>>
>> void* a_setlen( const void *a, unsigned len );
>>
>> If this function potentially invalidates the original "a"
>> object, such that the caller should capture the returned
>> pointer and stop using the pointer "a", then "const void
>> *" makes no sense.
>
> Yes, after calling: b = a_setlen( a, 55 ); `a' is no longer
> guaranteed to be point to a valid array, and `b' must be used
> thenceforward. This is exactly my case.
Destroying an object is mutation, so the const is a lie.
Note that the free function in ISO C is declared void free(void *),
and not void free(const void *). Same with the old pointer argument
of realloc.
You have to cast away the qualifier to use these functions on
a const pointer.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-18 07:21 -0700 |
| Message-ID | <865y47muix.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. [is the following declaration better?]
>
> void* a_setlen( const void *a, unsigned len )
> { [...]
> }
>
> especially considering that it is a `public' function,
> available to the programmer using the library?
(I removed the const-ness of the two function parameters as
that is not germane to my comments here.)
After reading your other responses I have something else to
add.
The added 'const' qualifier (ie, on the type of what a points to)
is bad. Besides being a hole in the type system, which may not
be a big deal, this declaration accepts 'const void *' arguments
without complaint. Presumably if someone has gone to the trouble
of declaring a variable (pointing to an extensible array) to be
const Foo *pfoo = ...; /* or perhaps a function parameter */
then they are expecting the array won't change out from under
them, including changing its length or adding new elements. So
we would like (or we think they would like) a call like
pfoo = a_setlen( pfoo );
to squawk, because pfoo is being used "wrongly", by virtue of its
having been declared 'const Foo *'. If this "wrongness" is what
they want, that should be asked for explicitly:
pfoo = a_setlen( (void*) pfoo );
So here I would advise against declaring the parameter a to be of
type 'const void *', and recommend 'void *a' be used in this
function definition.
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.lang.c
csiph-web