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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 18:52 +0200 |
| Message-ID | <uf1ml5$36bge$1@dont-email.me> |
| In reply to | #176539 |
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. However, your ideas that this is all about the sacred number 3 is nonsense. I have no problem using perhaps five levels of indirection in my code. I'd be fine with more too, but that would be very unlikely to occur simply because the function would be too big and complex, and would already be split up. I don't like more than one level of indirection, at least as raw pointers. "*p" is fine - "**p" is asking for confusion. "xs[1][2]" could be okay, but I rarely see use of anything more that is not better handled with local variables for the parts. For dimensions, two is usually the easiest. Thinking in four dimensions is possible to some extent, but definitely hard. (Thinking about more is fine in some ways, but then it's all pretty abstract mathematics.) For other people, the mixes and numbers might be entirely different, depending on their usual practices. The numbers don't line up. They are entirely different concepts. The only thing they have in common is a general pattern of "more is harder".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-27 10:46 -0700 |
| Message-ID | <03fb354b-016a-4451-887b-27dfa6c56f56n@googlegroups.com> |
| In reply to | #176541 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 20:26 +0200 |
| Message-ID | <uf1s5c$37jjc$1@dont-email.me> |
| In reply to | #176548 |
On 27/09/2023 19:46, 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? No, but not particularly relevant. Being able to think of a single situation where three things might be used together does not make them particularly related. Let me just ask you - have you ever written code with nesting that did not use indirection or dimensions? Of course you have. Have you ever had a 2 or more dimensional array, and used it in a way that did not involve indirection in the source code? Of course you have - people write "xs[1][2]", not some mess involving multiple pointer dereference operators. Have you ever used a pointer without nesting? Of course you have. These concepts are not closely related or tied together, even if they sometimes happen to be used in the same code. > Nesting, indirection, and dimensioning are all related to each other. No. > And we can visualise three dimensions easily enough, because we live > in a world with three dimensions of space. Yes. > To visualise four dimensions, > you have to add time, which makes it a different sort of mental exercise. No. You don't have to use time as the fourth dimension. Sometimes it can be convenient, but certainly not always. Sometimes you use time as a second or third dimension, sometimes you don't use it at all. I am quite happy imagining Klein bottles, hypercubes and 4-simplexes with four spacial dimensions. I am quite happy doing some maths with many-dimensional spheres (they have a few uses, and do weird things), with no sign of a time dimension. On the other hand, some physicists work with one physical dimension and three time dimensions. And sometimes it makes sense to think of all kinds of different properties of objects as "dimensions". Perhaps /you/ can only think of a fourth dimension as time, but please don't project your own limitations onto others. > > So three is the magic number. No. Seriously. Just "no". Even if you were right that nesting, indirection and dimensioning were strongly related - even though they most certainly are not - that would not make three a magic number. You really have to get off this hobby-horse you have invented. The more you repeat it and spout increasingly unsubstantiated post-rationalisations for your obsession, the more fanatical you look.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-27 11:45 -0700 |
| Message-ID | <87il7vsbdn.fsf@nosuchdomain.example.com> |
| In reply to | #176549 |
David Brown <david.brown@hesbynett.no> writes:
> On 27/09/2023 19:46, Malcolm McLean wrote:
[...]
>> So three is the magic number.
>
> No.
>
> Seriously. Just "no".
[...]
David, do you think you're going to change his mind?
This discussion will end at some point without a resolution.
I suggest that now would be a good time for that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-27 21:19 +0200 |
| Message-ID | <uf1v7f$389r0$1@dont-email.me> |
| In reply to | #176551 |
On 27/09/2023 20:45, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 27/09/2023 19:46, Malcolm McLean wrote: > [...] >>> So three is the magic number. >> >> No. >> >> Seriously. Just "no". > [...] > > David, do you think you're going to change his mind? > It seems unlikely, that's true. I am afraid my tactics may have been inspired by watching too much Black Adder. (If anyone wants a break from discussing C, look up "Advanced World War I Tactics with General Melchett" on youtube.) > This discussion will end at some point without a resolution. > I suggest that now would be a good time for that. > You are almost certainly right.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-27 16:34 -0700 |
| Message-ID | <uf2e6s$3arar$8@dont-email.me> |
| In reply to | #176553 |
On 9/27/2023 12:19 PM, David Brown wrote: > On 27/09/2023 20:45, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 27/09/2023 19:46, Malcolm McLean wrote: >> [...] >>>> So three is the magic number. >>> >>> No. >>> >>> Seriously. Just "no". >> [...] >> >> David, do you think you're going to change his mind? >> > > It seems unlikely, that's true. I am afraid my tactics may have been > inspired by watching too much Black Adder. Watch some mr flibble to attempt to try to cool any overheated jets: https://youtu.be/9-pnA0orMFU?t=67 ;^) (If anyone wants a break > from discussing C, look up "Advanced World War I Tactics with General > Melchett" on youtube.) > >> This discussion will end at some point without a resolution. >> I suggest that now would be a good time for that. >> > > You are almost certainly right. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-28 01:11 +0100 |
| Message-ID | <87il7vf96l.fsf@bsb.me.uk> |
| In reply to | #176553 |
David Brown <david.brown@hesbynett.no> writes: > On 27/09/2023 20:45, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 27/09/2023 19:46, Malcolm McLean wrote: >> [...] >>>> So three is the magic number. >>> >>> No. >>> >>> Seriously. Just "no". >> [...] >> David, do you think you're going to change his mind? > > It seems unlikely, that's true. Also, does it matter? It's not as if a rule has been put forward with such detail that someone new to C will come across the post and feel they must alter the way they write code to follow it. These things wind me up as well, but I just hit 'n' and I am all the happier for it! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-27 19:32 +0100 |
| Message-ID | <uf1sfp$37m2f$1@dont-email.me> |
| In reply to | #176548 |
On 27/09/2023 18:46, 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 don't think it works. Computer source code is usually 2-dimensional, tends to be limited horizontally, but has no particular limits vertically. The code unit is the 'function', which are not usually that tall, as they become unmanageable, and are not that wide either as people don't like scrolling sideways. That's why text like this wraps onto the next line, but that doesn't work for code which is line- not paragraph-oriented. When talking about function nesting, my own magic number is 1, and standard C doesn't allow more anyway. So people are welcome to limit those to three, as I don't care! But imagine applying the 'rule of three' to: - The number of lines in a function - The number of functions in a module - The number of modules in a program - The number of fields in a struct It doesn't work, does it? Or is this more about nesting? Was there also something about the number of nested parentheses in an expression? You don't really need a rule, as it will be obvious when there are far too many.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-27 17:12 -0700 |
| Message-ID | <ae6164a3-b59c-4b5f-b3f7-30e9ff1a9eban@googlegroups.com> |
| In reply to | #176550 |
On Wednesday, 27 September 2023 at 19:32:40 UTC+1, Bart wrote: > On 27/09/2023 18:46, 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 don't think it works. Computer source code is usually 2-dimensional, > tends to be limited horizontally, but has no particular limits vertically. > > The code unit is the 'function', which are not usually that tall, as > they become unmanageable, and are not that wide either as people don't > like scrolling sideways. That's why text like this wraps onto the next > line, but that doesn't work for code which is line- not paragraph-oriented. > > When talking about function nesting, my own magic number is 1, and > standard C doesn't allow more anyway. So people are welcome to limit > those to three, as I don't care! > > But imagine applying the 'rule of three' to: > > - The number of lines in a function > > - The number of functions in a module > > - The number of modules in a program > > - The number of fields in a struct > > It doesn't work, does it? Or is this more about nesting? > > Was there also something about the number of nested parentheses in an > expression? You don't really need a rule, as it will be obvious when > there are far too many. > If C allowed for nested functions then it would start to become hard for programmers to understand when the nesting level exceeded three. But the rule of three doesn't apply to metrics which don't bear a relationship to dimensions, like the number of lines in a function, or the number of fields in a struct. Here there may be other psychological limits, but they arise from different underlying causes. The rule of three does apply to parentheses. Here you can easily verify it. Simply write some expressions and note when the nesting starts to make understanding the expression harder rather than easier. Nesting has hierarchy whilst dimensions don't. And nesting doesn't have to be balanced, but nesting which represents a multi-dimensional array does have to be balanced. So it's related but not exactly the same thing (I really shouldn't have to make this simple point, however I do). You can't visualise a four-dimensional structure in your mind, and you can't take in more than three levels of nesting without consciously matching either.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-28 01:49 +0100 |
| Message-ID | <uf2ije$3bv1r$1@dont-email.me> |
| In reply to | #176590 |
On 28/09/2023 01:12, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 19:32:40 UTC+1, Bart wrote:
>> On 27/09/2023 18:46, 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 don't think it works. Computer source code is usually 2-dimensional,
>> tends to be limited horizontally, but has no particular limits vertically.
>>
>> The code unit is the 'function', which are not usually that tall, as
>> they become unmanageable, and are not that wide either as people don't
>> like scrolling sideways. That's why text like this wraps onto the next
>> line, but that doesn't work for code which is line- not paragraph-oriented.
>>
>> When talking about function nesting, my own magic number is 1, and
>> standard C doesn't allow more anyway. So people are welcome to limit
>> those to three, as I don't care!
>>
>> But imagine applying the 'rule of three' to:
>>
>> - The number of lines in a function
>>
>> - The number of functions in a module
>>
>> - The number of modules in a program
>>
>> - The number of fields in a struct
>>
>> It doesn't work, does it? Or is this more about nesting?
>>
>> Was there also something about the number of nested parentheses in an
>> expression? You don't really need a rule, as it will be obvious when
>> there are far too many.
>>
> If C allowed for nested functions then it would start to become hard for
> programmers to understand when the nesting level exceeded three.
>
> But the rule of three doesn't apply to metrics which don't bear a relationship
> to dimensions, like the number of lines in a function, or the number of
> fields in a struct. Here there may be other psychological limits, but they
> arise from different underlying causes.
>
> The rule of three does apply to parentheses. Here you can easily verify
> it. Simply write some expressions and note when the nesting starts to
> make understanding the expression harder rather than easier.
>
> Nesting has hierarchy whilst dimensions don't. And nesting doesn't have to
> be balanced, but nesting which represents a multi-dimensional array
> does have to be balanced. So it's related but not exactly the same thing (I
> really shouldn't have to make this simple point, however I do). You can't
> visualise a four-dimensional structure in your mind, and you can't take
> in more than three levels of nesting without consciously matching either.
No, 4 spatial dimensions is entirely different because we are only
familiar with 3. (Although could probably cope with projections of 4
into 3.)
But nesting levels are like Russian dolls; we can easily visualise half
dozen.
I've done a quick survey of my own codebase; maximum nesting, not
including functions and modules or any encapsulating type, is 6,
although that's unusual.
It's not a problem, because you don't need to 'get' the whole thing. If
you already have 4 levels, then the code at that 4th level needs:
if a then b else c
that is perfectly clear in that local context. It doesn't need relating
to all the outer levels. And within that new 5th level, you may have an
expression with parentheses; should those be added in too, or considered
separate? If the latter, than that's what happens with statement levels.
(BTW here is that 6-level chunk of a function:
https://github.com/sal55/langs/blob/master/nesting.m)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-27 17:53 -0700 |
| Message-ID | <uf2iqj$3bu8j$1@dont-email.me> |
| In reply to | #176594 |
On 9/27/2023 5:49 PM, Bart wrote: > On 28/09/2023 01:12, Malcolm McLean wrote: >> On Wednesday, 27 September 2023 at 19:32:40 UTC+1, Bart wrote: >>> On 27/09/2023 18:46, 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 don't think it works. Computer source code is usually 2-dimensional, >>> tends to be limited horizontally, but has no particular limits >>> vertically. >>> >>> The code unit is the 'function', which are not usually that tall, as >>> they become unmanageable, and are not that wide either as people don't >>> like scrolling sideways. That's why text like this wraps onto the next >>> line, but that doesn't work for code which is line- not >>> paragraph-oriented. >>> >>> When talking about function nesting, my own magic number is 1, and >>> standard C doesn't allow more anyway. So people are welcome to limit >>> those to three, as I don't care! >>> >>> But imagine applying the 'rule of three' to: >>> >>> - The number of lines in a function >>> >>> - The number of functions in a module >>> >>> - The number of modules in a program >>> >>> - The number of fields in a struct >>> >>> It doesn't work, does it? Or is this more about nesting? >>> >>> Was there also something about the number of nested parentheses in an >>> expression? You don't really need a rule, as it will be obvious when >>> there are far too many. >>> >> If C allowed for nested functions then it would start to become hard for >> programmers to understand when the nesting level exceeded three. >> >> But the rule of three doesn't apply to metrics which don't bear a >> relationship >> to dimensions, like the number of lines in a function, or the number of >> fields in a struct. Here there may be other psychological limits, but >> they >> arise from different underlying causes. >> >> The rule of three does apply to parentheses. Here you can easily verify >> it. Simply write some expressions and note when the nesting starts to >> make understanding the expression harder rather than easier. >> >> Nesting has hierarchy whilst dimensions don't. And nesting doesn't >> have to >> be balanced, but nesting which represents a multi-dimensional array >> does have to be balanced. So it's related but not exactly the same >> thing (I >> really shouldn't have to make this simple point, however I do). You >> can't >> visualise a four-dimensional structure in your mind, and you can't take >> in more than three levels of nesting without consciously matching either. > > No, 4 spatial dimensions is entirely different because we are only > familiar with 3. (Although could probably cope with projections of 4 > into 3.) > > But nesting levels are like Russian dolls; we can easily visualise half > dozen.[...] Think of using a 4'th component to be able to see through things. An alpha channel for a color, for instance.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-28 11:21 +0100 |
| Message-ID | <uf3k3r$3ku97$1@dont-email.me> |
| In reply to | #176594 |
On 28/09/2023 01:49, Bart wrote: > On 28/09/2023 01:12, Malcolm McLean wrote: >> Nesting has hierarchy whilst dimensions don't. And nesting doesn't >> have to >> be balanced, but nesting which represents a multi-dimensional array >> does have to be balanced. So it's related but not exactly the same >> thing (I >> really shouldn't have to make this simple point, however I do). You >> can't >> visualise a four-dimensional structure in your mind, and you can't take >> in more than three levels of nesting without consciously matching either. > I've done a quick survey of my own codebase; maximum nesting, not > including functions and modules or any encapsulating type, is 6, > although that's unusual. > (BTW here is that 6-level chunk of a function: > > https://github.com/sal55/langs/blob/master/nesting.m) Looking at line 20 of this extract, there is 'else' followed by 'case' (and the only statement in that branch) which is a candidate for my 'elsecase' feature. That would reduce nesting and indents by one level (and removes one block-terminating keyword). Actually, the C idiom to emulate if-elseif: 'if else if else ...' would normally involve N nesting levels, except that people ignore that and use fixed indentation. But the point is, it's not an extra cognitive load, because the structure is perceived as flat, not nested.
[toc] | [prev] | [next] | [standalone]
| From | Psychedelics Haven <psychedelicshaven@gmail.com> |
|---|---|
| Date | 2023-09-28 04:01 -0700 |
| Message-ID | <f8829ec8-4943-427e-b83d-487af68f1291n@googlegroups.com> |
| In reply to | #176628 |
https://psychedelicshaven.com/product/dmt-cartridge-1ml/ https://psychedelicshaven.com/product/ketamine-hcl-liquid/ https://psychedelicshaven.com/product/ibogaine-hcl/ https://psychedelicshaven.com/product/microdose-dmt/ https://psychedelicshaven.com/product/bruce-banner-strain/ https://psychedelicshaven.com/product/ak-47-strain/ https://psychedelicshaven.com/product/buy-honey-graham-bar/ https://psychedelicshaven.com/product/frozen-grapes-strain/ https://psychedelicshaven.com/product/chemdawg/ https://psychedelicshaven.com/product/captain-crunch-strain/ https://psychedelicshaven.com/product/bubba-kush-strain/ https://psychedelicshaven.com/product/jesus-og/ https://psychedelicshaven.com/product/jack-herer/ https://psychedelicshaven.com/product/gorilla-glue-weed/ https://psychedelicshaven.com/product/gelato-strain/ https://psychedelicshaven.com/product/be-renewed-psilocybin-capsules/ https://psychedelicshaven.com/product/buy-2b-c-online/ https://psychedelicshaven.com/product/buy-ketamine-pills-online/ https://psychedelicshaven.com/product/be-renewed-psilocybin-capsules/ https://psychedelicshaven.com/product/buy-chocolate-unicorns/ https://psychedelicshaven.com/product/buy-proscaline-microdose/ https://psychedelicshaven.com/product/buy-mdma-powder-online/ https://psychedelicshaven.com/product/iboga-root-bark-powder/ https://psychedelicshaven.com/product/rove-vape-carts/ https://psychedelicshaven.com/product/akuamma-seeds/ https://psychedelicshaven.com/product/order-moneybagg-runtz/ https://psychedelicshaven.com/product/og-kush/ https://psychedelicshaven.com/product/buy-chocolate-unicorns/ https://psychedelicshaven.com/product/buy-2b-c-online/ https://psychedelicshaven.com/product/buy-proscaline-microdose/ https://psychedelicshaven.com/product/fiyaman-carts/ https://psychedelicshaven.com/product/lsd-crystals/
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-28 16:56 +0300 |
| Message-ID | <20230928165630.41f579b0d75c8e45c3756490@gmail.moc> |
| In reply to | #176590 |
Malcolm McLean: > If C allowed for nested functions then it would start to > become hard for programmers to understand when the nesting > level exceeded three. > > But the rule of three doesn't apply to metrics which don't > bear a relationship to dimensions, like the number of > lines in a function, or the number of fields in a struct. > Here there may be other psychological limits, but they > arise from different underlying causes. > > The rule of three does apply to parentheses. Here you can > easily verify it. Simply write some expressions and note > when the nesting starts to make understanding the > expression harder rather than easier. > > Nesting has hierarchy whilst dimensions don't. And nesting > doesn't have to be balanced, but nesting which represents > a multi-dimensional array does have to be balanced. So > it's related but not exactly the same thing (I really > shouldn't have to make this simple point, however I do). > You can't visualise a four-dimensional structure in your > mind, and you can't take in more than three levels of > nesting without consciously matching either. Your argumentation apart, I tend to agree with your conclusion. I freely use nesting levels up to three, but beyond that I start having compunctions and seconds thoughts, and reviewing the functioon to check again if it cannot be split up. The rule of three is not is not a hard rule, but is there alright. Now I see how nesting is connected to dimentions: they both manifest the curse of deminsionality, or the exponential growth of complexity as the number of dimensions or the depth of nesting grows, for the number of (leaf) nodes in a tree is an exponent of its depth. -- () 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-28 07:15 -0700 |
| Message-ID | <11660097-99bd-45ae-9115-629962cf2f08n@googlegroups.com> |
| In reply to | #176651 |
On Thursday, 28 September 2023 at 14:56:46 UTC+1, Anton Shepelev wrote: > Malcolm McLean: > > If C allowed for nested functions then it would start to > > become hard for programmers to understand when the nesting > > level exceeded three. > > > > But the rule of three doesn't apply to metrics which don't > > bear a relationship to dimensions, like the number of > > lines in a function, or the number of fields in a struct. > > Here there may be other psychological limits, but they > > arise from different underlying causes. > > > > The rule of three does apply to parentheses. Here you can > > easily verify it. Simply write some expressions and note > > when the nesting starts to make understanding the > > expression harder rather than easier. > > > > Nesting has hierarchy whilst dimensions don't. And nesting > > doesn't have to be balanced, but nesting which represents > > a multi-dimensional array does have to be balanced. So > > it's related but not exactly the same thing (I really > > shouldn't have to make this simple point, however I do). > > You can't visualise a four-dimensional structure in your > > mind, and you can't take in more than three levels of > > nesting without consciously matching either. > Your argumentation apart, I tend to agree with your > conclusion. I freely use nesting levels up to three, but > beyond that I start having compunctions and seconds > thoughts, and reviewing the functioon to check again if it > cannot be split up. The rule of three is not is not a hard > rule, but is there alright. > Yes. Whilst Linus Torvalds and I largely agree, I don't impose the rule of three on C function curly braces. There are several reasons. Most C programmers use vertical alignment to increase the visual prominence of the nesting. Then nesting can be for nested iteration (in which case maximum three levels are appropriate), but it can also be for nested if statements. The whilst it is helpful to be able to read a function as one unit, taking it all in as a whole, in a procedural programming language like C, it isn't really necessary. The fundamental basic structure of a C function is a list, not a nest. So for those reasons, my own view is that we can tolerate C functions which break the rule of three. But Linus Torvalds is an exceptionally able programmer. > > Now I see how nesting is connected to dimentions: they both > manifest the curse of deminsionality, or the exponential > growth of complexity as the number of dimensions or the > depth of nesting grows, for the number of (leaf) nodes in a > tree is an exponent of its depth. > Exactly. Another psychological rule is that you can take in seven objects without counting them. Now imagine we have a binary tree. The number of nodes per level is 1, 2 ,4, 8, 16. So what's the nesting level at which you can take in all of the tree at a glance?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-28 18:38 +0300 |
| Message-ID | <20230928183847.4f8165c1b57cb5234b7469d1@gmail.moc> |
| In reply to | #176652 |
Malcolm McLean: > Another psychological rule is that you can take in seven > objects without counting them. It is not pshychologica rule, but rather an experimentally determined established fact from cognitive scence. I had it in mind but never mentioned somehow. You beat me to it. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-28 21:47 +0200 |
| Message-ID | <uf4l89$3r5qi$1@dont-email.me> |
| In reply to | #176656 |
On 28/09/2023 17:38, Anton Shepelev wrote: > Malcolm McLean: > >> Another psychological rule is that you can take in seven >> objects without counting them. > > It is not pshychologica rule, but rather an experimentally > determined established fact from cognitive scence. I had it > in mind but never mentioned somehow. You beat me to it. > It is not a rule at all. It's a myth. When I was a kid, these kind of things spread around the playground - you can only hold 7 bits of information in your mind at a time, you can count up to but not more than 7 objects in a glance, you can fold a piece of paper at most 7 times, and so on. Then we grew older and realised it was all nonsense - it all depends on the person, the information, the objects and their arrangements, the type of paper. Now there is social media to keep adults drenched in this kind of easily digested urban myth, and lots of people fall for "proof by repeated assertion" rather than rubbing two brain cells together and thinking about reality. Please put some thought into this, and perhaps a little research, instead of assuming random things someone once told you are scientifically established fact.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-29 01:45 +0300 |
| Message-ID | <20230929014522.eb87102dc07b8cec01be2c4d@gmail.moc> |
| In reply to | #176665 |
David Brown: > When I was a kid, these kind of things spread around the > playground - you can only hold 7 bits of information in > your mind at a time, you can count up to but not more than > 7 objects in a glance, you can fold a piece of paper at > most 7 times, and so on. Then we grew older and realised > it was all nonsense - it all depends on the person, the > information, the objects and their arrangements, the type > of paper. > [...] > Please put some thought into this, and perhaps a little > research, instead of assuming random things someone once > told you are scientifically established fact. <https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two> -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-29 10:38 +0200 |
| Message-ID | <uf62e2$6fjg$1@dont-email.me> |
| In reply to | #176677 |
On 29/09/2023 00:45, Anton Shepelev wrote: > David Brown: > >> When I was a kid, these kind of things spread around the >> playground - you can only hold 7 bits of information in >> your mind at a time, you can count up to but not more than >> 7 objects in a glance, you can fold a piece of paper at >> most 7 times, and so on. Then we grew older and realised >> it was all nonsense - it all depends on the person, the >> information, the objects and their arrangements, the type >> of paper. >> [...] >> Please put some thought into this, and perhaps a little >> research, instead of assuming random things someone once >> told you are scientifically established fact. > > <https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two> > Did you note the title of that page (and the book it refers to) ? The error margin of plus/minus 2 ? The wiki page notes that 7 is not "magic", and that sometimes 4 is equally "magic". Did you know that while scientists may write books, and some books are mostly factual, writing a book does /not/ mean something is established scientific fact? Did you know that psychology and cognitive sciences are amongst the least "factual" of sciences, because it is almost never possible to do proper controlled or repeatable experiments? They do the best they can, but few results rise about the level of "possible indication", and almost nothing in the field qualifies as "scientific fact" or "scientific law". The great thing about scientific laws is that you only need a single example to disprove them. Think about situations where you have to deal with long strings of digits (such as reference codes when paying bills). If there are more than perhaps 4 repeated digits in a row, most people have to count them, and with 6 or more digits they'll count them several times to be confident. So the "magic number" is clearly 4. Try rolling two normal dice. You'll identify the total spot count immediately, at a glance, without counting or adding up. So the "magic number" is clearly 12. It has been pointed out that Malcolm is pretty much beyond saving in his beliefs in various "laws" he invents. Please do not follow him.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-29 14:33 +0300 |
| Message-ID | <20230929143353.5cb171a0c85af3da0f61257c@gmail.moc> |
| In reply to | #176711 |
David Brown to Anton Shepelev: > > David Brown: > > > > > Please put some thought into this, and perhaps a > > > little research, instead of assuming random things > > > someone once told you are scientifically established > > > fact. > > > > <https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two> > > Did you note the title of that page (and the book it > refers to) ? It is not a book, just a paper in a scentific journal. > The error margin of plus/minus 2? Yes, and it may be not the error margin but the distribution width among various people. Metaphorically, this is the number of our internal "registers". Although it is not an exact number, neither it is "a random thing once told me". It is based on research. It is only mathematics that works with exact quantities, whereas in science they are always known with a degree of uncertainly, even the gravity constant G. > The wiki page notes that 7 is not "magic", It only reports Miller's "reflection" that the correspondence between the limits of one-dimensional absolute judgment and of short-term memory span was only a coincidence, because only the first limit, not the second, can be characterized in information-theoretic terms (i.e., as a roughly constant number of bits). Therefore, there is nothing "magical" about the number seven, and Miller used the expression only rhetorically. It still is magical (special) in the sense that it characterises our average memory span better than any other number. What definition of magic do you use? For instance, I do not believe in the Cabbalah -- the Jewish numeric magic... > and that sometimes 4 is equally "magic". Perhaps you are confusing memory capacity (2-3 bits) and memory span (5-9) in that article. > Did you know that while scientists may write books, and > some books are mostly factual, writing a book does /not/ > mean something is established scientific fact? A book, or more frequently, a paper) is based on research. A high-quality research, independently repeated by other scientists and not yet found to be seriously flawed establishes a scientific fact. Theoreticaly, another experiment may disprove or correct it any day. > Did you know that psychology and cognitive sciences are > amongst the least "factual" of sciences, because it is > almost never possible to do proper controlled or > repeatable experiments? It is hard, but not almost impossible. There have been wonderfully deep cognitive experiments that gave insights into brain physiology, such as Benjamin Libet's. > They do the best they can, but few results rise about the > level of "possible indication", and almost nothing in the > field qualifies as "scientific fact" or "scientific law". I don't think you are right here. A lot of precise results have been obtained, such as the lower boundary for reaction time, or knowledge about color perception. > Think about situations where you have to deal with long > strings of digits (such as reference codes when paying > bills). If there are more than perhaps 4 repeated digits > in a row, most people have to count them, and with 6 or > more digits they'll count them several times to be > confident. So the "magic number" is clearly 4. This is about readability, as is the grouping of decimal numbers by three (Malcom's rule of thee!). > Try rolling two normal dice. You'll identify the total > spot count immediately, at a glance, without counting or > adding up. So the "magic number" is clearly 12. Not at all. It is the limitation of the dice, not of the thrower. You have suggested a number of experiemnts with various results in each. They do not in any way disprove Miller's conclusion, but measure different quantities (call them magic, if you will -- I do not). Nor do people who remember the sequence of cards from four to six shuffled card stacks in memory contests. > It has been pointed out that Malcolm is pretty much beyond > saving in his beliefs in various "laws" he invents. > Please do not follow him. I think you exagerrate about his inventing of "laws", but I for one told him I did not agree with his argumentation by appeal to the three dimensions of the Euclicdean space, which looks more like a coincidence to me. In fact, I am not aware of "laws" that he has purely invented and is following to the letter (or digit). If, for example, some fundamental algoritym consists of four nested loops, I do not believe Malcoms with split it into two functions simply beause it violates the rule of three. There should be additonal reasons and considerations. The number three, for example, has been prominent in culture of thousands of years. Think of Trinitiy, of the proverb "Third time pays for all" -- it is not the second or fourth time, but always the third -- at least in European and Russian folklore. We often make three attempts before giving up, not two, nor four. Neither two or four are so prominent, which makes three somehow special. Perhaps Malcom is consciously applying this arhetypal knowledge to his work in programming: three is an agressive upper bound on the depth of a hierarchy (to keep it easily perceptible), and seven -- on the number of things one can comfortably have in focus simultaneosly while reading code. The latter is a wild conjecture on my part. It is not something I consiously rely on. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web