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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-27 16:32 -0700 |
| Message-ID | <uf2e2g$3arar$7@dont-email.me> |
| In reply to | #176584 |
On 9/27/2023 4:29 PM, Chris M. Thomasson wrote: > On 9/27/2023 10:46 AM, Malcolm McLean wrote: >> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote: >>> On 27/09/2023 17:35, Malcolm McLean wrote: >>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote: >>>>> On 27/09/2023 12:37, Malcolm McLean wrote: >>>>> >>>>>> (Nesting, indirection, and dimensioning are all related to each >>>>>> other). >>>>> No, they are not. >>>>> >>>> You haven't thought this through, have you? >>> Yes, I have. >>> >>> I mean, obviously if you want to have an n-dimensional array and loop >>> through it all, you'll have n levels of nesting, and your array access >>> is technically through pointers with n levels of indirection. >>> >> Exactly. Not exactly a controversial idea, is it? >> Nesting, indirection, and dimensioning are all related to each other. >> And we can visualise three dimensions easily enough, because we live >> in a world with three dimensions of space. To visualise four dimensions, >> you have to add time, which makes it a different sort of mental exercise. >> >> So three is the magic number. > > I personally think that time is an interesting form of quantitative > "special", and not a dimension as is simply because time exists in every > dimension. Is that kind of, fair enough? For instance, think of a 4d being looking into a 3d realm, and noticing a clock hanging on a wall. Well, the 4d being can use the clock to sync itself with the time in the 3d realm of that room that contains the clock. Is this too out there? Sorry. ;^o
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-28 21:24 -0700 |
| Message-ID | <uf5jim$3tkq$3@dont-email.me> |
| In reply to | #176585 |
On 9/27/2023 4:32 PM, Chris M. Thomasson wrote: > On 9/27/2023 4:29 PM, Chris M. Thomasson wrote: >> On 9/27/2023 10:46 AM, Malcolm McLean wrote: >>> On Wednesday, 27 September 2023 at 17:53:10 UTC+1, David Brown wrote: >>>> On 27/09/2023 17:35, Malcolm McLean wrote: >>>>> On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote: >>>>>> On 27/09/2023 12:37, Malcolm McLean wrote: >>>>>> >>>>>>> (Nesting, indirection, and dimensioning are all related to each >>>>>>> other). >>>>>> No, they are not. >>>>>> >>>>> You haven't thought this through, have you? >>>> Yes, I have. >>>> >>>> I mean, obviously if you want to have an n-dimensional array and loop >>>> through it all, you'll have n levels of nesting, and your array access >>>> is technically through pointers with n levels of indirection. >>>> >>> Exactly. Not exactly a controversial idea, is it? >>> Nesting, indirection, and dimensioning are all related to each other. >>> And we can visualise three dimensions easily enough, because we live >>> in a world with three dimensions of space. To visualise four dimensions, >>> you have to add time, which makes it a different sort of mental >>> exercise. >>> >>> So three is the magic number. >> >> I personally think that time is an interesting form of quantitative >> "special", and not a dimension as is simply because time exists in >> every dimension. Is that kind of, fair enough? > > For instance, think of a 4d being looking into a 3d realm, and noticing > a clock hanging on a wall. Well, the 4d being can use the clock to sync > itself with the time in the 3d realm of that room that contains the > clock. Is this too out there? Sorry. ;^o I was thinking that this theoretical 4d being can most definitely observe its lower dimensions, so to speak. And a clock in a lower dimension is something that this 4d being can look at and sync with. Fair enough?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-27 23:05 +0300 |
| Message-ID | <20230927230537.620dabf22ed22fb31e09f9ec@gmail.moc> |
| In reply to | #176539 |
Malcolm McLean: > David Brown: > > Malcolm McLean: > > > > > (Nesting, indirection, and dimensioning are all > > > related to each other). > > > > No, they are not. > > You haven't thought this through, have you? I agree with David. Dimensions entities on the level. They are orthogonal and equal, that is you cannot place them into any kind of hierarchy, in which, for example, height is below or above width. Dimensions form an unordered set (the tautology rhetorical). Not so with nesting and indirection, which express a hierarchy and form an ordered sequence (the tautology rhetorical). -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-27 14:18 -0700 |
| Message-ID | <uf267e$39oal$2@dont-email.me> |
| In reply to | #176461 |
On 9/26/2023 8:29 AM, Malcolm McLean wrote: > On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote: >> On 26/09/2023 13:37, Anton Shepelev wrote: >>> >>> 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. 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. >> > Rule of three. Three levels of nesting or indirection. Because we live in a three > dimensional world. Personally, I have never heard of that rule before Malcolm. However, if I was working for you, I would learn about it and strive to follow it because you would be my boss in this scenario. No problem. Section 3.2 page 12: https://www.stroustrup.com/JSF-AV-rules.pdf
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-26 16:57 +0100 |
| Message-ID | <ueuv1r$2iped$1@dont-email.me> |
| In reply to | #176458 |
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.
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-26 16:40 +0000 |
| Message-ID | <20230926093309.110@kylheku.com> |
| In reply to | #176462 |
On 2023-09-26, Bart <bc@freeuk.com> 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.
The actual rules is that the required braces, comprising a compound
statement, can be prefixed by something which modifies the statement
into a conditional.
>
> 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.
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.
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. :)
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 */;
Some languages combine "else" and "if" into a single token, even.
The C preprocessing language is like that: #elif.
--
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-26 18:46 +0100 |
| Message-ID | <uev5e6$2k5cd$1@dont-email.me> |
| In reply to | #176463 |
On 26/09/2023 17:40, Kaz Kylheku wrote:
> On 2023-09-26, Bart <bc@freeuk.com> wrote:
>> On 26/09/2023 16:10, David Brown wrote:
>> What is the actual rule about braces? Because you've clearly missed some
>> out there, in omitting them around the first two 'else' branches.
>
> The actual rules is that the required braces, comprising a compound
> statement, can be prefixed by something which modifies the statement
> into a conditional.
But then that compound statement becomes a single statement with no
braces of its own, and many of the problems associated with optional
braces return.
>> 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.
>
> 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.
Suppose you were to write it like this:
} else
for (...) {
then someone adds an extra statement:
} else
puts("Loop follows.");
for (...) {
Now it's not so cool.
Really, it's quite silly: how far deep inside a series of /single/
nested statements are you allowed to go, to enable you to claim that
your 'else' branch is actually brace-delimited?
> What I wouldn't write is:
>
>
> if (condition) {
> /* loop not needed */
> } else
Why wouldn't you write this? Presumably something might be added there
in future, otherwise it's a poorly thought-out condition.
> Some languages combine "else" and "if" into a single token, even.
> The C preprocessing language is like that: #elif.
This has always puzzled me, where C's preprocessor has a more grown-up,
more solid , more readable and less error prone syntax than the main
language. No dangling 'else' there!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 11:37 +0200 |
| Message-ID | <uf0t4p$314n3$1@dont-email.me> |
| In reply to | #176464 |
On 26/09/2023 19:46, Bart wrote:
> On 26/09/2023 17:40, Kaz Kylheku wrote:
>> On 2023-09-26, Bart <bc@freeuk.com> wrote:
>>> On 26/09/2023 16:10, David Brown wrote:
>
>>> What is the actual rule about braces? Because you've clearly missed some
>>> out there, in omitting them around the first two 'else' branches.
>>
>> The actual rules is that the required braces, comprising a compound
>> statement, can be prefixed by something which modifies the statement
>> into a conditional.
>
> But then that compound statement becomes a single statement with no
> braces of its own, and many of the problems associated with optional
> braces return.
>
>>> 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.
>>
>> 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.
>
> Suppose you were to write it like this:
>
>
> } else
> for (...) {
>
> then someone adds an extra statement:
>
> } else
> puts("Loop follows.");
> for (...) {
>
> Now it's not so cool.
>
Exactly. The "else if" shortcut, IMHO, should only ever be for "else
if", and the attached actions need to be in braces. Then there are no
ambiguities, and minimal risk for mistakes if someone adds to the code
later.
> Really, it's quite silly: how far deep inside a series of /single/
> nested statements are you allowed to go, to enable you to claim that
> your 'else' branch is actually brace-delimited?
>
>
>> What I wouldn't write is:
>>
>>
>> if (condition) {
>> /* loop not needed */
>> } else
>
> Why wouldn't you write this? Presumably something might be added there
> in future, otherwise it's a poorly thought-out condition.
I assumed from his post (Kaz can correct me if I'm wrong) that it was
the second half of that example that he saw as a problem. The full case
was :
if (condition) {
/* loop not needed */
} else for (...)
/* empty */;
To me, there are several things wrong here - so I certainly won't write
it. But empty bodies in conditionals do turn up sometimes, if that's
the clearest way to write the conditionals. They can be a good
placeholder for comments explaining the reasoning in the code, or - as
you suggest - for possible future additions.
if ((x >= 0) && (y >= 0)) {
// Both non-negative, so nothing to do here
} else if (x >= 0) {
y = x; // Fix negative y
} else if (y >= 0) {
x = y; // Fix negative x
} else {
panic(); // x and y should not both be negative
}
Of course the ordering could be changed, or the tests could be
re-arranged, so that the empty statement is not needed. But sometimes
code clarity suggests a pattern including empty statements.
I will even write something like this on occasion :
if (<complicated condition>) {
// Everything is fine, nothing to do
} else {
do_something();
}
rather than
if (!(<complicated condition>)) {
do_something();
}
It is all about what is clearest to read.
>
>> Some languages combine "else" and "if" into a single token, even.
>> The C preprocessing language is like that: #elif.
>
> This has always puzzled me, where C's preprocessor has a more grown-up,
> more solid , more readable and less error prone syntax than the main
> language. No dangling 'else' there!
>
C doesn't need an "elseif", since it has "else if" that does exactly the
same job. There are no circumstances (AFAICS) where you could use an
"elseif" keyword but not "else if".
For the preprocessor, you could not have "#else #if", thus you need a
separate preprocessor directive.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-27 15:13 +0300 |
| Message-ID | <20230927151302.f1b8f4a162a805a9ba1688ab@gmail.moc> |
| In reply to | #176524 |
David Brown:
> But sometimes
> code clarity suggests a pattern including empty statements.
>
> I will even write something like this on occasion :
>
> if (<complicated condition>) {
> // Everything is fine, nothing to do
> } else {
> do_something();
> }
>
> rather than
>
> if (!(<complicated condition>)) {
> do_something();
> }
Sometimes my arrangement is decided by which conditional
expression is simpler. When the branches are extremely
unbalanced, that is one is one is very long and the other a
one-liner, I will put the short one into the then-clause,
because the layout is better:
if( <condition> ) one_liner(); if( <condition> )
else { a = rather(long);
{ a = rather(long); and(cumbersome);
and(cumbersome); multiline();
multiline(); paragraph(of);
paragraph(of); code();
code(); }
} else one_liner();
When two thrirds of a long function is the code of some
special conditional processing, sometimes I prefer to jump
over it with a `goto' to save a level of indentation:
function struct baz ver_1(int b) function struct baz ver_1(int b)
{ int a = normal_proc_1(b ); { int a = normal_proc_1(b );
int c = normal_proc_2(a, b); int c = normal_proc_2(a, b);
if( special ) if( !special ) goto SKIP_SPECIAL;
{ spec_t = spec_init(a,c);
if( special_test(s) ) spec_t s = spec_init(a,c);
{ s1 = do_foo(s); if( special_test(s) )
s2 = do_bar(s); { s1 = do_foo(s);
if( s1 > s2 ) s2 = do_bar(s);
{ c = calc_c(a, s1, s2,); if( s1 > s2 )
many(); { c = calc_c(a, s1, s2,);
more(); many();
lines(); more();
here(); lines();
} here();
} }
special_finalize(c); }
} special_finalize(c);
temp = finalize(c); SKIP_SPECIAL:
if( test( temp ) ) temp = finalize(c);
{ update(c); } if( test( temp ) )
return c; { update(c); }
} return c;
}
Do all present vehemently condemn this practice?
Christopher Seiwald's seventh pillar seems to encourage
it[1]:
The left edge of the code defines its structure, while
the right side holds the detail. You must fight
indentation to safeguard this property. Code which moves
too quickly from left to right (and back again) mixes
major control flow with minor detail.
Forcibly align the main flow of control down the left
side, with one level of indentation for
if/while/for/do/switch statements. Use break, continue,
return, even 'goto' to coerce the code into left-side
alignment. Rearrange conditionals so that the block with
the quickest exit comes first, and then return (or break,
or continue) so that the other leg can continue at the
same indentation level.
> For the preprocessor, you could not have "#else #if", thus
> you need a separate preprocessor directive.
I think this is possible, but only hierarchically:
#if M1
...
#else
#if M2
...
#else
#if M3
...
#endif
#endif
#endif
Therefore, #elseif is introduced not to add a new possiblity
but to let the programmer express what was already possible
in a layout that better reflects his intent.
____________________
1. <https://web.archive.org/web/20100227185627/http://www.perforce.com/perforce/papers/prettycode.html>
--
() 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-27 13:32 +0100 |
| Message-ID | <uf17dn$33109$1@dont-email.me> |
| In reply to | #176524 |
On 27/09/2023 10:37, David Brown wrote:
> I will even write something like this on occasion :
>
> if (<complicated condition>) {
> // Everything is fine, nothing to do
> } else {
> do_something();
> }
>
> rather than
>
> if (!(<complicated condition>)) {
> do_something();
> }
>
> It is all about what is clearest to read.
I have a version of 'if' called 'unless', which sometimes reads better,
but not always.
In particular, although 'unless' can have an 'else' branch, it doesn't
have 'else-unless'; I couldn't work out what it meant!
Also, while C has 'do...while', my equivalent is 'repeat...until', with
the opposite logic.
I can't have repeat...while as that is ambiguous: the 'while' could be
starting a new loop. Actually I had some troubling figuring out how C
manages to avoid the same problem.
(Note that I can write C's
do {a;b;c;} while (cond);
as:
while a;b;c; cond do end
Ugly, though.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 19:00 +0200 |
| Message-ID | <uf1n3q$36bge$2@dont-email.me> |
| In reply to | #176529 |
On 27/09/2023 14:32, Bart wrote:
> On 27/09/2023 10:37, David Brown wrote:
>
>
>> I will even write something like this on occasion :
>>
>> if (<complicated condition>) {
>> // Everything is fine, nothing to do
>> } else {
>> do_something();
>> }
>>
>> rather than
>>
>> if (!(<complicated condition>)) {
>> do_something();
>> }
>>
>> It is all about what is clearest to read.
>
> I have a version of 'if' called 'unless', which sometimes reads better,
> but not always.
>
> In particular, although 'unless' can have an 'else' branch, it doesn't
> have 'else-unless'; I couldn't work out what it meant!
There are a few different varieties of conditionals that have been tried
in different programming languages. That includes syntaxes roughly like
"x = x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I
have remembered the details correctly. I don't think it really helps to
have too many ways of doing the same thing - there has to be very clear
gains to make it worth the effort.
>
> Also, while C has 'do...while', my equivalent is 'repeat...until', with
> the opposite logic.
That's fine - I think either works well.
>
> I can't have repeat...while as that is ambiguous: the 'while' could be
> starting a new loop. Actually I had some troubling figuring out how C
> manages to avoid the same problem.
>
>
> (Note that I can write C's
>
> do {a;b;c;} while (cond);
>
> as:
>
> while a;b;c; cond do end
>
> Ugly, though.)
>
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-28 01:34 +0100 |
| Message-ID | <87cyy3f858.fsf@bsb.me.uk> |
| In reply to | #176545 |
David Brown <david.brown@hesbynett.no> writes:
> On 27/09/2023 14:32, Bart wrote:
>> On 27/09/2023 10:37, David Brown wrote:
>>
>>> I will even write something like this on occasion :
>>>
>>> if (<complicated condition>) {
>>> // Everything is fine, nothing to do
>>> } else {
>>> do_something();
>>> }
>>>
>>> rather than
>>>
>>> if (!(<complicated condition>)) {
>>> do_something();
>>> }
>>>
>>> It is all about what is clearest to read.
>> I have a version of 'if' called 'unless', which sometimes reads better,
>> but not always.
>> In particular, although 'unless' can have an 'else' branch, it doesn't
>> have 'else-unless'; I couldn't work out what it meant!
>
> There are a few different varieties of conditionals that have been tried in
> different programming languages. That includes syntaxes roughly like "x =
> x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I have
> remembered the details correctly. I don't think it really helps to have
> too many ways of doing the same thing - there has to be very clear gains to
> make it worth the effort.
The biggest departure are multi-way ifs like
if C1 -> S1
C2 -> S2
...
fi
I've even come across a language where the while loop had the same
structure with do ... od in place of if .. fi. For example
do a > b -> a :=: b
b > c -> b :=: c
od
where :=: is a swap operator ensures that the values in a, b and c are
in non-decreasing order.
One variation (I think it was used in S-Algol) is to have a case
statement where the arms can have arbitrary expressions. A multi-way
if then looks like this:
case true of
x > 0: return +1
x == 0: return 0
x < 0: return -1
esac
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-28 10:08 +0200 |
| Message-ID | <uf3c9n$3jdkk$1@dont-email.me> |
| In reply to | #176592 |
On 28/09/2023 02:34, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 27/09/2023 14:32, Bart wrote:
>>> On 27/09/2023 10:37, David Brown wrote:
>>>
>>>> I will even write something like this on occasion :
>>>>
>>>> if (<complicated condition>) {
>>>> // Everything is fine, nothing to do
>>>> } else {
>>>> do_something();
>>>> }
>>>>
>>>> rather than
>>>>
>>>> if (!(<complicated condition>)) {
>>>> do_something();
>>>> }
>>>>
>>>> It is all about what is clearest to read.
>>> I have a version of 'if' called 'unless', which sometimes reads better,
>>> but not always.
>>> In particular, although 'unless' can have an 'else' branch, it doesn't
>>> have 'else-unless'; I couldn't work out what it meant!
>>
>> There are a few different varieties of conditionals that have been tried in
>> different programming languages. That includes syntaxes roughly like "x =
>> x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I have
>> remembered the details correctly. I don't think it really helps to have
>> too many ways of doing the same thing - there has to be very clear gains to
>> make it worth the effort.
>
> The biggest departure are multi-way ifs like
>
> if C1 -> S1
> C2 -> S2
> ...
> fi
Yes, especially if the choice is non-deterministic (that is, if the C2
and C3 are both true, then one of S2 or S3 will happen, but you don't
control which). That would probably surprise many programmers of
traditional languages, but I can see it having clear benefits. For
example, an "abs" function could be :
if x >= 0 -> return x;
x <= 0 -> return -x;
fi
Then it's up to the compiler to figure out the most efficient way to
make the code, using either return path in the case x == 0.
I can't think off-hand of a language that supports such overlapping
cases in that way. (Of course compilers can always do things like that
when following the "as if" rule.)
>
> I've even come across a language where the while loop had the same
> structure with do ... od in place of if .. fi. For example
>
> do a > b -> a :=: b
> b > c -> b :=: c
> od
>
> where :=: is a swap operator ensures that the values in a, b and c are
> in non-decreasing order.
>
> One variation (I think it was used in S-Algol) is to have a case
> statement where the arms can have arbitrary expressions. A multi-way
> if then looks like this:
>
> case true of
> x > 0: return +1
> x == 0: return 0
> x < 0: return -1
> esac
>
Is that really much different from :
if (x > 0) return -1;
if (x == 0) return 0;
if (x < 0) return -1;
?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-28 10:37 +0100 |
| Message-ID | <uf3hhh$3kcto$1@dont-email.me> |
| In reply to | #176614 |
On 28/09/2023 09:08, David Brown wrote:
> On 28/09/2023 02:34, Ben Bacarisse wrote:
>> One variation (I think it was used in S-Algol) is to have a case
>> statement where the arms can have arbitrary expressions. A multi-way
>> if then looks like this:
>>
>> case true of
>> x > 0: return +1
>> x == 0: return 0
>> x < 0: return -1
>> esac
>>
>
> Is that really much different from :
>
> if (x > 0) return -1;
> if (x == 0) return 0;
> if (x < 0) return -1;
>
> ?
Yes, it's all encapsulated within one construct. With the separate ifs,
you add arbitrary statements between then, which is likely not possible
with the case.
Also, if you were to have something other then a return for 'x==0', the
case probably wouldn't fall through to the x<0 test, but it will do for
the ifs.
Further (I don't know if that is the case for that language, but it is
for mine), you might be able to write the case version like this:
return case true of
x > 0: +1
x == 0: 0
x < 0: -1
esac
or even leave out the 'return' completely if this is last statement in a
function. With the ifs, only the third 'if' is the last statement.
In short, the case is properly structured. The 'if' version is more like
early Fortran.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-28 14:13 +0200 |
| Message-ID | <uf3qkq$3m38j$1@dont-email.me> |
| In reply to | #176616 |
On 28/09/2023 11:37, Bart wrote: > On 28/09/2023 09:08, David Brown wrote: >> On 28/09/2023 02:34, Ben Bacarisse wrote: > >>> One variation (I think it was used in S-Algol) is to have a case >>> statement where the arms can have arbitrary expressions. A multi-way >>> if then looks like this: >>> >>> case true of >>> x > 0: return +1 >>> x == 0: return 0 >>> x < 0: return -1 >>> esac >>> >> >> Is that really much different from : >> >> if (x > 0) return -1; >> if (x == 0) return 0; >> if (x < 0) return -1; >> >> ? > > Yes, it's all encapsulated within one construct. With the separate ifs, > you add arbitrary statements between then, which is likely not possible > with the case. That's true. But is there a semantic difference, when there are no arbitrary statements between them? (I'm a fan of constructs that have limits on what they allow, so I can see a point in such as "case" statement even if the meanings are the same.) > > Also, if you were to have something other then a return for 'x==0', the > case probably wouldn't fall through to the x<0 test, but it will do for > the ifs. Yes, but that makes no difference in this situation. (It would make a difference if there were overlaps in the conditionals, or if the conditionals had side-effects.) > > Further (I don't know if that is the case for that language, but it is > for mine), you might be able to write the case version like this: > > return case true of > x > 0: +1 > x == 0: 0 > x < 0: -1 > esac > > or even leave out the 'return' completely if this is last statement in a > function. With the ifs, only the third 'if' is the last statement. > > In short, the case is properly structured. The 'if' version is more like > early Fortran. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-28 13:50 +0100 |
| Message-ID | <87pm22ea2q.fsf@bsb.me.uk> |
| In reply to | #176614 |
David Brown <david.brown@hesbynett.no> writes: > On 28/09/2023 02:34, Ben Bacarisse wrote: >> One variation (I think it was used in S-Algol) is to have a case >> statement where the arms can have arbitrary expressions. A multi-way >> if then looks like this: >> >> case true of >> x > 0: return +1 >> x == 0: return 0 >> x < 0: return -1 >> esac > > Is that really much different from : > > if (x > 0) return -1; > if (x == 0) return 0; > if (x < 0) return -1; > > ? Well, for one thing, the same syntax[1] supports other forms of case like C's switch and so on. Another difference is that it can obviously be an expression: sign := case true of x > 0: +1 | x = 0: 0 | x < 0: -1 esac But I suppose it all depends on your metric for "really much different from". [1] I doubt that exact syntax would be used since the cases are only recognised by <expression> ':' which is not a fixed-length look-ahead. There would likely be a separator as I've added in the expression example. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-28 16:37 +0300 |
| Message-ID | <20230928163759.44f96470d469247e2668c2ce@gmail.moc> |
| In reply to | #176614 |
David Brown to Ben Bacarisse: > > case true of > > x > 0: return +1 > > x == 0: return 0 > > x < 0: return -1 > > esac > > Is that really much different from : > > if (x > 0) return -1; > if (x == 0) return 0; > if (x < 0) return -1; > > ? Yes. The perfect alignment of Ben's code assists comprehension by arranging the elements meaninfully, so that analogous parts are stricly under one another. It also utilises a higher-level structure directly to express the programmer's conceptual intent of dispatching by a condition. Your code lacks horsontal alignment and is just a sequence of syntatically independent `if' statements, leaving a gap between the programmer's concuptual intent and its expression in the code. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-28 14:46 +0000 |
| Message-ID | <0lgRM.217413$GHI6.174295@fx17.iad> |
| In reply to | #176592 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>David Brown <david.brown@hesbynett.no> writes:
>
>> On 27/09/2023 14:32, Bart wrote:
>>> On 27/09/2023 10:37, David Brown wrote:
>>>
>>>> I will even write something like this on occasion :
>>>>
>>>> 牋牋爄f (<complicated condition>) {
>>>> 牋牋牋牋 // Everything is fine, nothing to do
>>>> 牋牋爙 else {
>>>> 牋牋牋牋 do_something();
>>>> 牋牋爙
>>>>
>>>> rather than
>>>>
>>>> 牋牋爄f (!(<complicated condition>)) {
>>>> 牋牋牋牋 do_something();
>>>> 牋牋爙
>>>>
>>>> It is all about what is clearest to read.
>>> I have a version of 'if' called 'unless', which sometimes reads better,
>>> but not always.
>>> In particular, although 'unless' can have an 'else' branch, it doesn't
>>> have 'else-unless'; I couldn't work out what it meant!
>>
>> There are a few different varieties of conditionals that have been tried in
>> different programming languages. That includes syntaxes roughly like "x =
>> x - 1 if x > 0", or FORTH's "x ? 0 > if x ? 1 - x ! then", if I have
>> remembered the details correctly. I don't think it really helps to have
>> too many ways of doing the same thing - there has to be very clear gains to
>> make it worth the effort.
>
>The biggest departure are multi-way ifs like
>
> if C1 -> S1
> C2 -> S2
> ...
> fi
>
>I've even come across a language where the while loop had the same
>structure with do ... od in place of if .. fi. For example
>
> do a > b -> a :=: b
> b > c -> b :=: c
> od
>
>where :=: is a swap operator ensures that the values in a, b and c are
>in non-decreasing order.
>
>One variation (I think it was used in S-Algol) is to have a case
>statement where the arms can have arbitrary expressions. A multi-way
>if then looks like this:
>
> case true of
> x > 0: return +1
> x == 0: return 0
> x < 0: return -1
> esac
Then there is BPL:
DEFINE IN_ = BEGIN BEGIN UNSEGMENTED #,
OUT_ = END ELSE BEGIN UNSEGMENTED #,
ELSE_ = END ELSE BEGIN UNSEGMENTED #,
ELIF_ = END ELSE IF #,
THEN_ = THEN BEGIN UNSEGMENTED #,
UNTIL_(C) = ; IF C THEN EXITLOOP; #,
WHILE_(C) = ; IF NOT C THEN EXITLOOP; #,
END_ = END #,
FI_ = FI #,
OD_ = OD #,
ESAC_ = ESAC #,
EXITBLOCK_ = EXITBLOCK #,
EXITCOND_ = EXITCOND #,
EXITLOOP_ = EXITLOOP #,
EXITCASE_ = EXITCASE #,
GOTOTOPLOOP_ = TOPLOOP #,
TOPLOOP_ = TOPLOOP #;
...
DO_ IF_ voiding 01031000
THEN_ DO_ WHILE_ (input_sequence_number 01032000
<= last_image_to_void) 01033000
READ INPDOC [endfile]; &72 TEXT CHARACTERS 01034000
input_line := inp_dummy; & P_00001035000
OD &8 SEQUENCE NUMBERS 01036000
ELSE_ READ INPDOC [endfile]; 01037000
input_line := inp_dummy; & P_00001038000
save_seq_numb := input_sequence_number; & P_00201039000
FI; 01040000
01041000
text_ptr := [input_line.+67]; &BEGINNING OF LAST 5 01042000
DO_ WHILE_ (next_5_input_characters = blank) 01043000
adr_dec (text_ptr,10); 01044000
UNTIL_ (text_ptr <= [input_line.+5]) 01045000
OD; 01046000
01047000
adr_inc (text_ptr, 8); &END OF FIRST NON 01048000
&BLANK PENTAD OR LEFT 01049000
&MOST PENTAD 01050000
DO_ WHILE_ (next_input_character = blank) 01051000
adr_dec (text_ptr, 2); 01052000
UNTIL_ (text_ptr <= [input_line]) 01053000
OD; 01054000
WHILE_ (current_mode ^= as_entered_mode) 01055000
&EMPTIES 01056000
UNTIL_ (text_ptr >= [input_line]) &ENTERED 01057000
OD; 01058000
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 11:23 +0200 |
| Message-ID | <uf0s9s$30uj6$2@dont-email.me> |
| In reply to | #176463 |
On 26/09/2023 18:40, Kaz Kylheku wrote:
> On 2023-09-26, Bart <bc@freeuk.com> 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.
>
> The actual rules is that the required braces, comprising a compound
> statement, can be prefixed by something which modifies the statement
> into a conditional.
>>
>> 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.
>
> 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 ( ... ) {
...
}
}
>
> 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. :)
Eek!
>
> 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.
> Some languages combine "else" and "if" into a single token, even.
> The C preprocessing language is like that: #elif.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-27 11:42 +0100 |
| Message-ID | <uf10up$31pin$1@dont-email.me> |
| In reply to | #176521 |
On 27/09/2023 10:23, David Brown wrote:
> On 26/09/2023 18:40, Kaz Kylheku wrote:
>> 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.
My language has 'if-elsif', 'case' and 'switch' selection statements
which can each have arbitrarily long sequences of tests.
Each can have an optional 'else' branch. (When used inside an
expression, which is not often, the whole thing returns a value so the
'else' is needed.)
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.
I don't have elsefor, that never comes up and doesn't make sense. But I
do have looping forms of switch/case called doswitch and docase, which
are used extensively.
(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.)
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web