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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-27 15:27 +0300 |
| Message-ID | <20230927152759.8c60e82f32aecacadc83ea1b@gmail.moc> |
| In reply to | #176526 |
Bart:
> Now, brace yourself... sometimes a series of tests changes
> between if, case and switch, so I allow these to be mixed
> within the same statement:
>
> if c1 then
> elsif c2 then
> elsecase x1
> ...
> elsif c3 then
> ...
> elseswitch x2
> ...
> end
>
> This just saves having deeply nested statements when the
> testing pattern is really linear.
It looks awkward to me, especially without any horisontal
alignment, but your rationale is sound: the concept of
chaining branching statements is orthogonal to the the kind
individual statements, so that mixing them must be logical.
> (My 'switch' has the same restrictions as C's, plus it
> must be implementable as a jump table. 'case' has the same
> syntax, but no restrictions, and testing is sequential.)
You said upthread that one of your multiple-select
statements was more like SQL's CASE, i.e. able to dispatch
by condition /and/ by a value.
For lack of a special provision for a linear if-else chains,
I sometimes use a sequence of normal `if' statements with
`goto':
if( c1 ) { x = v1 ; goto X_SET; }
if( c2 ) { x = v2 ; goto X_SET; }
if( c3 ) { x = v3 ; goto X_SET; }
x = v_def;
X_SET:
/* continue with x ... */
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-27 06:44 -0700 |
| Message-ID | <4085f2b1-5d8e-4479-a983-5581cea49b53n@googlegroups.com> |
| In reply to | #176528 |
On Wednesday, 27 September 2023 at 13:28:15 UTC+1, Anton Shepelev wrote:
> Bart:
> > Now, brace yourself... sometimes a series of tests changes
> > between if, case and switch, so I allow these to be mixed
> > within the same statement:
> >
> > if c1 then
> > elsif c2 then
> > elsecase x1
> > ...
> > elsif c3 then
> > ...
> > elseswitch x2
> > ...
> > end
> >
> > This just saves having deeply nested statements when the
> > testing pattern is really linear.
> It looks awkward to me, especially without any horisontal
> alignment, but your rationale is sound: the concept of
> chaining branching statements is orthogonal to the the kind
> individual statements, so that mixing them must be logical.
> > (My 'switch' has the same restrictions as C's, plus it
> > must be implementable as a jump table. 'case' has the same
> > syntax, but no restrictions, and testing is sequential.)
> You said upthread that one of your multiple-select
> statements was more like SQL's CASE, i.e. able to dispatch
> by condition /and/ by a value.
>
> For lack of a special provision for a linear if-else chains,
> I sometimes use a sequence of normal `if' statements with
> `goto':
>
> if( c1 ) { x = v1 ; goto X_SET; }
> if( c2 ) { x = v2 ; goto X_SET; }
> if( c3 ) { x = v3 ; goto X_SET; }
> x = v_def;
> X_SET:
> /* continue with x ... */
>
I'd find that confusing. Are c1, c2, c3 mutually exclusive? If so, why are they
separate conditions? If more than one is true, the first option is chosen. But
why?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-27 17:56 +0300 |
| Message-ID | <20230927175646.0b69b35a85c6105a06a773d9@gmail.moc> |
| In reply to | #176530 |
Malcolm McLean to Anton Shepelev:
> > For lack of a special provision for a linear if-else
> > chains, I sometimes use a sequence of normal `if'
> > statements with `goto':
> >
> > if( c1 ) { x = v1 ; goto X_SET; }
> > if( c2 ) { x = v2 ; goto X_SET; }
> > if( c3 ) { x = v3 ; goto X_SET; }
> > x = v_def;
> > X_SET:
> > /* continue with x ... */
>
> I'd find that confusing. Are c1, c2, c3 mutually
> exclusive? If so, why are they separate conditions? If
> more than one is true, the first option is chosen. But
> why?
Thay may or may not be mutually exclusive. My point is,
that whichever the case, the code above behaves identically
to the if-else chain:
if( c1 ) x = v1 ;
else if( c2 ) x = v2 ;
else if (c3 ) x = v3 ;
else x = v_def;
--
() 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-27 22:12 +0000 |
| Message-ID | <20230927143445.556@kylheku.com> |
| In reply to | #176521 |
On 2023-09-27, David Brown <david.brown@hesbynett.no> wrote:
> On 26/09/2023 18:40, Kaz Kylheku wrote:
>> Indeed, I myself sometimes writes in a style like the following:
>>
>> if (condition) {
>> /* loop not needed */
>> } else for (...) {
>>
>> }
>>
>> The else keyword needs a statement, and the for statement
>> satisfies it. It has braces of its own, so everything is cool.
>
> I would not go that far. "else if" in C is, to me, a short form for
> "elseif" or "elsif" found in other languages. I've never seen an
> "elsefor" or "elsewhile" keyword.
>
> "if, else if, else" chains are common and fit a nice pattern. But a
> "for" loop is completely different, breaking the pattern - I'd have it
> in its own braces :
>
> if (...) {
> ...
> } else {
> for ( ... ) {
> ...
> }
> }
Yes; this is the widely used, familiar way of writing this situation.
I think I grew tired of it at some point.
>> The for (...) header is effectively a statement prefix which indicates
>> iteration of that statement.
>>
>> In my style, I allow the braced statement to be prefixed not only
>> by if (...) but other, similar statement introducers/prefixes
>> like while (...) and switch.
>>
>> I don't think I've ever written a
>>
>> if (this) {
>>
>> } else do {
>>
>> } while(...);
>>
>> But I totally might. :)
I wrote the above unware that I'm lying. In the TXR project, I'm
somewhat astonished to see that an "else do" occurs. What's more,
it dates back to a commit, on Christmas Day, 2011. (Ho, ho, ho!)
https://www.kylheku.com/cgit/txr/commit/?id=894aec019d3ce82f861a5777236ac079c2f2388d
in the function lazy_flatten_scan.
static val lazy_flatten_scan(val list, val *escape)
{
for (;;) {
if (list) {
val a = car(list);
if (nilp(a)) {
list = cdr(list);
} else if (atom(a)) {
return list;
} else do {
push(cdr(list), escape); /* safe mutation: *escape is a local var */
list = a;
a = car(list);
} while (consp(a));
return list;
} else if (*escape) {
list = pop(escape);
} else {
return nil;
}
}
}
I had no idea I've been doing it that long already, and that
a "do" might have started it.
In that code base there are two cases of "else for", and one "else
switch", which came later. It's far from frequent.
I can't find any instances of
else {
<for|while|switch|do> ...
>> What I wouldn't write is:
>>
>>
>> if (condition) {
>> /* loop not needed */
>> } else for (...)
>> body_expression_statement;
>>
>> Or, let alone:
>>
>> if (condition) {
>> /* loop not needed */
>> } else for (...)
>> /* empty */;
>>
>
> No, indeed.
>
The reason I wouldn't write that has nothing to do with that last
clause being an iteration statement. It's because of the same old
rule that all parts of the ladder have to be free of braces, or else all
have to have them:
This example is a "go":
if (condition)
simple_statement;
else while (--i)
foo(j++);
If simple_statement becomes a compound, then it's "no go".
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-27 23:53 +0100 |
| Message-ID | <uf2bpe$3asqk$1@dont-email.me> |
| In reply to | #176569 |
On 27/09/2023 23:12, Kaz Kylheku wrote:
> On 2023-09-27, David Brown <david.brown@hesbynett.no> wrote:
> https://www.kylheku.com/cgit/txr/commit/?id=894aec019d3ce82f861a5777236ac079c2f2388d
>
> in the function lazy_flatten_scan.
>
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (list) {
> val a = car(list);
> if (nilp(a)) {
> list = cdr(list);
> } else if (atom(a)) {
> return list;
> } else do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> } else if (*escape) {
> list = pop(escape);
> } else {
> return nil;
> }
> }
> }
>
> I had no idea I've been doing it that long already, and that
> a "do" might have started it.
>
> In that code base there are two cases of "else for", and one "else
> switch", which came later. It's far from frequent.
I don't know why this is remarkable. So, an 'else' branch has a
statement that happens to be a loop or switch statement? I'm sure that
happens all the time whether there's an intervening brace or not!
> I can't find any instances of
>
> else {
> <for|while|switch|do> ...
There are quite a few around. 25 instances in sqlite3 for example, and 5
in Lua sources. I mean, it might be 1 per 5-10K lines, but people do it.
In C, you can find instances of anything.
>>> What I wouldn't write is:
>>>
>>>
>>> if (condition) {
>>> /* loop not needed */
>>> } else for (...)
>>> body_expression_statement;
>>>
>>> Or, let alone:
>>>
>>> if (condition) {
>>> /* loop not needed */
>>> } else for (...)
>>> /* empty */;
>>>
>>
>> No, indeed.
>>
>
> The reason I wouldn't write that has nothing to do with that last
> clause being an iteration statement. It's because of the same old
> rule that all parts of the ladder have to be free of braces, or else all
> have to have them:
>
> This example is a "go":
>
> if (condition)
> simple_statement;
> else while (--i)
> foo(j++);
>
> If simple_statement becomes a compound, then it's "no go".
What about when simple_statement becomes:
if (condition) another_stmt;
Then that 'else' becomes bound to the wrong 'if'.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-28 16:25 +0300 |
| Message-ID | <20230928162530.dc7fcd418865f9409f987e43@gmail.moc> |
| In reply to | #176569 |
Kaz Kylheku:
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (list) {
> val a = car(list);
> if (nilp(a)) {
> list = cdr(list);
> } else if (atom(a)) {
> return list;
> } else do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> } else if (*escape) {
> list = pop(escape);
> } else {
> return nil;
> }
> }
> }
I took this as an exercise in linearising nested if's:
static val lazy_flatten_scan(val list, val *escape)
{
for (;;) {
if (!list) {
if( !*escape ) return nil; /* Ant: no need of else after return */
/* Ant: henceforth, *escape */
list = pop( escape );
continue;
}
/* Ant: henceforth, list != NULL */
val a = car(list);
/* Ant: henceforth, we have a */
if(nilp(a)) {
list = cdr(list);
continue;
}
/* Ant: henceforth, !nilp(a) */
if (atom(a)) return list; /* Ant: no need of else after return */
/* Ant: henceforth, !atom(a) */
do {
push(cdr(list), escape); /* safe mutation: *escape is a local var */
list = a;
a = car(list);
} while (consp(a));
return list;
}
}
I deal with conditions step by step, adding invariants as
execution moves down. I start with the shorter branches, to
minimise amount of highly indented code, until at the end I
can write the `do' loop (the most complex branch) without
any encircling conditionals.
--
() 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-28 17:00 +0000 |
| Message-ID | <20230928094424.105@kylheku.com> |
| In reply to | #176648 |
On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
> Kaz Kylheku:
>
>> static val lazy_flatten_scan(val list, val *escape)
>> {
>> for (;;) {
>> if (list) {
>> val a = car(list);
>> if (nilp(a)) {
>> list = cdr(list);
>> } else if (atom(a)) {
>> return list;
>> } else do {
>> push(cdr(list), escape); /* safe mutation: *escape is a local var */
>> list = a;
>> a = car(list);
>> } while (consp(a));
>> return list;
>> } else if (*escape) {
>> list = pop(escape);
>> } else {
>> return nil;
>> }
>> }
>> }
>
> I took this as an exercise in linearising nested if's:
>
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (!list) {
> if( !*escape ) return nil; /* Ant: no need of else after return */
> /* Ant: henceforth, *escape */
> list = pop( escape );
> continue;
> }
> /* Ant: henceforth, list != NULL */
> val a = car(list);
> /* Ant: henceforth, we have a */
>
> if(nilp(a)) {
> list = cdr(list);
> continue;
> }
> /* Ant: henceforth, !nilp(a) */
>
> if (atom(a)) return list; /* Ant: no need of else after return */
> /* Ant: henceforth, !atom(a) */
>
> do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> }
> }
I might have had that function in tail recursive form
initially, which would look like:
static val lazy_flatten_scan(val list, val *escape)
{
// nothing in list: consume the escape stack.
if (!list) {
// nothing in escape stack: we are done
if( !*escape )
return nil;
return lazy_flatten_scan(pop(escape), escape);
}
val a = car(list);
// first element is empty list: scan the rest
if (nilp(a))
return lazy_flatten_scan(cdr(list), escape);
// first element is atom: return this list
// (caller consumes the atom and marches down the list)
if (atom(a))
return list;
// first element is a list: we drill into it, and keep iterating
// until we hit a list whose first element isn't another non-empty
// list, all the while while pushing the return path of lists we
// have visited into the escape stack.
do {
push(cdr(list), escape); /* safe mutation: *escape is a local var */
list = a;
a = car(list);
} while (consp(a)); // we found a list whose first item isn't
return list;
}
The do/while could probably be eliminated via a suitable tail call also;
I'm not going into it.
--
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-30 09:58 -0700 |
| Message-ID | <86zg13egxu.fsf@linuxsc.com> |
| In reply to | #176648 |
Anton Shepelev <anton.txt@gmail.moc> writes:
> Kaz Kylheku:
>
>> static val lazy_flatten_scan(val list, val *escape)
>> {
>> for (;;) {
>> if (list) {
>> val a = car(list);
>> if (nilp(a)) {
>> list = cdr(list);
>> } else if (atom(a)) {
>> return list;
>> } else do {
>> push(cdr(list), escape); /* safe mutation: *escape is a local var */
>> list = a;
>> a = car(list);
>> } while (consp(a));
>> return list;
>> } else if (*escape) {
>> list = pop(escape);
>> } else {
>> return nil;
>> }
>> }
>> }
>
> I took this as an exercise in linearising nested if's:
>
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (!list) {
> if( !*escape ) return nil; /* Ant: no need of else after return */
> /* Ant: henceforth, *escape */
> list = pop( escape );
> continue;
> }
> /* Ant: henceforth, list != NULL */
> val a = car(list);
> /* Ant: henceforth, we have a */
>
> if(nilp(a)) {
> list = cdr(list);
> continue;
> }
> /* Ant: henceforth, !nilp(a) */
>
> if (atom(a)) return list; /* Ant: no need of else after return */
> /* Ant: henceforth, !atom(a) */
>
> do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> }
> }
>
> I deal with conditions step by step, adding invariants as
> execution moves down. I start with the shorter branches, to
> minimise amount of highly indented code, until at the end I
> can write the `do' loop (the most complex branch) without
> any encircling conditionals.
Do you think the revised code does the same thing
as the original?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-10-01 00:41 +0300 |
| Message-ID | <20231001004147.ad8db455ae5be4755fff0168@gmail.moc> |
| In reply to | #176817 |
Tim Rentsch:
> Anton Shepelev <anton.txt@gmail.moc> writes:
>
> > Kaz Kylheku:
> >
> >> static val lazy_flatten_scan(val list, val *escape)
> >> {
> >> for (;;) {
> >> if (list) {
> >> val a = car(list);
> >> if (nilp(a)) {
> >> list = cdr(list);
> >> } else if (atom(a)) {
> >> return list;
> >> } else do {
> >> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> >> list = a;
> >> a = car(list);
> >> } while (consp(a));
> >> return list;
> >> } else if (*escape) {
> >> list = pop(escape);
> >> } else {
> >> return nil;
> >> }
> >> }
> >> }
> >
> > I took this as an exercise in linearising nested if's:
> >
> > static val lazy_flatten_scan(val list, val *escape)
> > {
> > for (;;) {
> > if (!list) {
> > if( !*escape ) return nil; /* Ant: no need of else after return */
> > /* Ant: henceforth, *escape */
> > list = pop( escape );
> > continue;
> > }
> > /* Ant: henceforth, list != NULL */
> > val a = car(list);
> > /* Ant: henceforth, we have a */
> >
> > if(nilp(a)) {
> > list = cdr(list);
> > continue;
> > }
> > /* Ant: henceforth, !nilp(a) */
> >
> > if (atom(a)) return list; /* Ant: no need of else after return */
> > /* Ant: henceforth, !atom(a) */
> >
> > do {
> > push(cdr(list), escape); /* safe mutation: *escape is a local var */
> > list = a;
> > a = car(list);
> > } while (consp(a));
> > return list;
> > }
> > }
> >
> > I deal with conditions step by step, adding invariants as
> > execution moves down. I start with the shorter branches, to
> > minimise amount of highly indented code, until at the end I
> > can write the `do' loop (the most complex branch) without
> > any encircling conditionals.
>
> Do you think the revised code does the same thing
> as the original?
I intended it to be, but since the purpose was to show an
approach, I did not actually test my code as that would
require some work of setting up the test environment.
--
() 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-30 22:33 +0000 |
| Message-ID | <20230930150347.479@kylheku.com> |
| In reply to | #176836 |
On 2023-09-30, Anton Shepelev <anton.txt@gmail.moc> wrote: > Tim Rentsch: >> Do you think the revised code does the same thing >> as the original? > > I intended it to be, but since the purpose was to show an > approach, I did not actually test my code as that would > require some work of setting up the test environment. If I plug it into the program and try a few test cases interactively, I'm not seeing any difference. It doesn't appear that there are differences in the function that are relevant to its caller. Under appears to be "bug for bug compatible". (The original is buggy; I fixed it already and covered it with test cases, which can't be used for this exercise.) Buggy original: 1> (flatten* '(a b c)) (a b c) 2> (flatten* '(a (b c))) (a b c) 3> (flatten* '((a) (b c))) (a b c) 4> (flatten* '((()) (b c))) (nil b c) 5> (flatten* '((()) (b ()))) (nil b) 6> (flatten* '((()) (b (())))) (nil b nil) 7> (flatten* '(a (b (c (d))))) (a b c d) 8> (flatten* '((((a))))) (a) With Anton's lazy_flatten_scan: 1> (flatten* '(a b c)) (a b c) 2> (flatten* '(a (b c))) (a b c) 3> (flatten* '((a) (b c))) (a b c) 4> (flatten* '((()) (b c))) (nil b c) 5> (flatten* '((()) (b ()))) (nil b) 6> (flatten* '((()) (b (())))) (nil b nil) 7> (flatten* '(a (b (c (d))))) (a b c d) 8> (flatten* '((((a))))) (a) The function is lazy, so it can flatten an infinite list. E.g. this works in both; regular flatten will hang: 1> (take 2 (flatten* (repeat '(a (b c))))) (a b) Naturally, I'm not motivated to thorougly test something I'm not planning to integrate. -- 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@gmail.moc> |
|---|---|
| Date | 2023-10-01 01:50 +0300 |
| Message-ID | <20231001015045.84b7e320bf103ec38adf4058@gmail.moc> |
| In reply to | #176837 |
Kaz Kylheku: > Naturally, I'm not motivated to thorougly test something > I'm not planning to integrate. Of course, I only wanted to share it to demonstrate my approach of flattening deep nesting. -- () 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-30 09:56 -0700 |
| Message-ID | <864jjbfvlc.fsf@linuxsc.com> |
| In reply to | #176569 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[.. combining 'else' with 'for' or 'while', etc ..]
> [from some code written in 2011]
>
> static val lazy_flatten_scan(val list, val *escape)
> {
> for (;;) {
> if (list) {
> val a = car(list);
> if (nilp(a)) {
> list = cdr(list);
> } else if (atom(a)) {
> return list;
> } else do {
> push(cdr(list), escape); /* safe mutation: *escape is a local var */
> list = a;
> a = car(list);
> } while (consp(a));
> return list;
> } else if (*escape) {
> list = pop(escape);
> } else {
> return nil;
> }
> }
> }
>
> I had no idea I've been doing it that long already, and that
> a "do" might have started it. [...]
This code is truly horrific.
Ironically, combining 'do' directly with 'else' may be
responsible for a bug in the code.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-30 17:42 +0000 |
| Message-ID | <20230930101010.225@kylheku.com> |
| In reply to | #176816 |
On 2023-09-30, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [.. combining 'else' with 'for' or 'while', etc ..]
>
>
>> [from some code written in 2011]
>>
>> static val lazy_flatten_scan(val list, val *escape)
>> {
>> for (;;) {
>> if (list) {
>> val a = car(list);
>> if (nilp(a)) {
>> list = cdr(list);
>> } else if (atom(a)) {
>> return list;
>> } else do {
>> push(cdr(list), escape); /* safe mutation: *escape is a local var */
>> list = a;
>> a = car(list);
>> } while (consp(a));
>> return list;
>> } else if (*escape) {
>> list = pop(escape);
>> } else {
>> return nil;
>> }
>> }
>> }
>>
>> I had no idea I've been doing it that long already, and that
>> a "do" might have started it. [...]
>
> This code is truly horrific.
>
> Ironically, combining 'do' directly with 'else' may be
> responsible for a bug in the code.
Seeing you say there is a problem in that area, I reproduced a
problem on first try. That loop drills into left nesting at the front of
the list: (((...)) ...)
Cases like ((())) do not flatten correctly; the empty list is treated as an
atom, resulting in (nil) which is identical to (()). The correct
result is ().
The do loop takes matters into its own hands, so to speak, and isn't
checking for the case when a is nil.
The following change fixes it:
--- a/lib.c
+++ b/lib.c
@@ -3671,7 +3671,6 @@ static val lazy_flatten_scan(val list, val *escape)
list = a;
a = car(list);
} while (consp(a));
- return list;
} else if (*escape) {
list = pop(escape);
} else {
but that just shows that the loop is not only insufficient (since we have to
rely on the main loop to handle a case after it is done), but unnecessary.
In that else block we can just descend one level the left nesting, push one
level into the escape stack, and continue with the main loop:
--- a/lib.c
+++ b/lib.c
@@ -3666,12 +3666,11 @@ static val lazy_flatten_scan(val list, val *escape)
list = cdr(list);
} else if (atom(a)) {
return list;
- } else do {
+ } else {
push(cdr(list), escape); /* safe mutation: *escape is a local var */
list = a;
a = car(list);
- } while (consp(a));
- return list;
+ }
} else if (*escape) {
list = pop(escape);
} else {
I might also remove the surrounding for (;;) and rely on tail calls.
The root cause of the problem is lack of test coverage, which has to be
addressed first. I wouldn't write anything like this without a ton of tests
today, but some old functions in the project are uncovered.
Thanks for the review; unless you object, I will credit you in
the commit message.
--
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-30 15:42 -0700 |
| Message-ID | <86v8bre10k.fsf@linuxsc.com> |
| In reply to | #176829 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > Thanks for the review; unless you object, I will credit you in > the commit message. I'd prefer not to have any attribution. I'm glad my comments helped you track down the problem.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 11:19 +0200 |
| Message-ID | <uf0s28$30uj6$1@dont-email.me> |
| In reply to | #176462 |
On 26/09/2023 17:57, Bart wrote:
> On 26/09/2023 16:10, David Brown wrote:
>> On 26/09/2023 13:37, Anton Shepelev wrote:
>
>>> if( test_1 ) stat_1;
>>> else if( test_2 ) stat_2;
>>> else if( test_3 ) stat_3;
>>>
>>
>> These are both wrong :-)
>>
>>
>> if (test1) {
>> stat_1;
>> } else if (test2) {
>> stat_2;
>> } else if (test3) {
>> stat_3;
>> } else {
>> ...
>> }
>>
>> That is clearer than yours, and far more maintainable. 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.
>
> What is the actual rule about braces? Because you've clearly missed some
> out there, in omitting them around the first two 'else' branches.
It is certainly /possible/ to put in more braces (that is possible in a
great many places in C code). And you do have a valid argument for
consistency.
However, "else if" can be viewed as the C equivalent of "elseif" or
"elsif", as found in some other languages. This leads itself to a
simple and clear pattern like this. Sometimes such patterns can be more
important for clarity than the general rules.
>
> If you saying this is OK, then that's playing fast and rule with any
> such rule that braces must always be used even around one statement.
>
You are correct that my rules (and most people's rules) for braces are
not quite simple.
I am also quite happy with simple, short and unambiguous (no macros)
statements on the same line :
if (!p) return;
if (x > 0) x--;
But if things are more complex - the conditional is larger, the
statement is not "simple" (I admit that I am not defining "simple"
here), or the total line is getting too long, then I put in the braces
and indentation. Spilling to a second line without having the braces is
definitely wrong.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-26 20:53 +0300 |
| Message-ID | <20230926205357.930d996e817bd458e0ff656b@gmail.moc> |
| In reply to | #176458 |
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. 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.
> > 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.
> 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.
> > 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.
> 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?
> > 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.
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.
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; |
} |
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. 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.
> > 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. 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.
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.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-26 19:15 +0100 |
| Message-ID | <uev74t$2kgdi$1@dont-email.me> |
| In reply to | #176466 |
On 26/09/2023 18:53, Anton Shepelev wrote:
> David Brown to Anton Shepelev:
>> 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?
If I take that example, with an extra branch:
if (test1) {
stat_1;
} else if (test2) {
stat_2;
} else if (test3) {
stat_3;
} else if (test4) {
stat_4;
} else {
stat_5;
}
and pass it through a visualisation tool that turns it into my syntax, I
get this:
if test1 then
stat_1
else
if test2 then
stat_2
else
if test3 then
stat_3
else
if test4 then
stat_4
else
stat_5
fi
fi
fi
fi
The indent level expands sideways as the length of the chain increases.
(Actully I can see the same thing when looking at the generated AST.)
I need a way to detect whether an if-else-if chain was intended, because
that is not the natural form of such a sequence in C. If successul, that
output would instead be:
if test1 then
stat_1
elsif test2 then
stat_2
elsif test3 then
stat_3
elsif test4 then
stat_4
else
stat_5
fi
But I'm not sure that can be done in foolproof manner. Maybe the intent
of the original C /was/ a nested structure with increasing indents.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-26 23:05 +0000 |
| Message-ID | <20230926122027.184@kylheku.com> |
| In reply to | #176467 |
On 2023-09-26, Bart <bc@freeuk.com> wrote:
> and pass it through a visualisation tool that turns it into my syntax, I
> get this:
>
> if test1 then
> stat_1
> else
> if test2 then
> stat_2
> else
> if test3 then
> stat_3
> else
> if test4 then
> stat_4
> else
> stat_5
> fi
> fi
> fi
> fi
>
> The indent level expands sideways as the length of the chain increases.
> (Actully I can see the same thing when looking at the generated AST.)
In Lisp there is no such conundrum.
(if test-1
stat-1
(if test2
stat-2
(if test3
stat-3
(if test4
stat-4
stat-5))))
There is no ladder coding style to make this vertical; any attempt to
make one would be repugnant, due to incorrect indentation:
(if test-1
stat-1
(if test2
stat-2
(if test3
stat-3
(if test4
stat-4
stat-5))))
You'd be constantly fighting with the editor which would be indenting
it.
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))
Note that cond came before if. It allowed (cond (x y) (t z)) to be
condensed to (if x y z). Originally, cond clauses were strictly
pairs called "cond pairs". In ANSI Common Lisp they can have one
or more clauses. If the first expression is true, the remaining
expresssions, if any, are evaluated. The value of the last expression
in the clause becomes the result; thus (cond (3)) yields 3.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-27 01:45 +0100 |
| Message-ID | <uevtup$2of5s$1@dont-email.me> |
| In reply to | #176499 |
On 27/09/2023 00:05, Kaz Kylheku wrote: > On 2023-09-26, Bart <bc@freeuk.com> wrote: >> and pass it through a visualisation tool that turns it into my syntax, I >> get this: >> >> if test1 then >> stat_1 >> else >> if test2 then >> stat_2 >> else >> if test3 then >> stat_3 >> else >> if test4 then >> stat_4 >> else >> stat_5 >> fi >> fi >> fi >> fi >> >> The indent level expands sideways as the length of the chain increases. >> (Actully I can see the same thing when looking at the generated AST.) > > In Lisp there is no such conundrum. > > (if test-1 > stat-1 > (if test2 > stat-2 > (if test3 > stat-3 > (if test4 > stat-4 > stat-5)))) > > There is no ladder coding style to make this vertical; any attempt to > make one would be repugnant, due to incorrect indentation: > > (if test-1 > stat-1 > (if test2 > stat-2 > (if test3 > stat-3 > (if test4 > stat-4 > stat-5)))) > > You'd be constantly fighting with the editor which would be indenting > it. > > 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. 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!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-26 19:43 -0700 |
| Message-ID | <87y1gss5dq.fsf@nosuchdomain.example.com> |
| In reply to | #176502 |
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?
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.
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.
--
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]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web