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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-18 17:15 +0000 |
| Message-ID | <20230918095305.817@kylheku.com> |
| In reply to | #175909 |
On 2023-09-18, David Brown <david.brown@hesbynett.no> wrote:
> On 18/09/2023 10:53, Anton Shepelev wrote:
>> Tim Rentsch to Anton Shepelev:
>>
>> [an unused variable removed from quoted code:]
>>>> void* a_setlen( void * a, unsigned len )
>>>> { struct meta_t *m ;
>>>>
>>>> m = META ( a );
>>>> m = setlen( m, len );
>>>> if( m != NULL ) a = DATA( m );
>>>> else a = NULL ;
>>>> return a;
>>>> }
>>>
>>> Is there some reason not to write a shorter and simpler
>>> function, such as the function below (please ignore
>>> differences in layout style)
>>>
>>> void*
>>> a_setlen( void *a, unsigned n ){
>>> struct meta_t *const m = setlen( META( a ), n );
>>>
>>> return m ? DATA( m ) : NULL;
>>> }
>>
>> My personal reasons are the following:
>>
>> 1. I prefer not to mix variable declaration and
>> initialisation, but first to declare my data and then
>> to work with it.
>
> Why? I've seen people give good reasons for this habit, and bad reasons
> for it, so I'm curious as to /your/ reasons!
>
>
> I prefer not to declare any variable until I have a proper
> initialisation for it.
C90 syntax supports this by allowing nested compound statements to
introduce declarations.
{
int yes = 1;
setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, &yes, sizeof yes);
}
This has advantages. We control not only the start of the identifier's
scope, but also the end.
We can copy and paste this in the same function (if for whatever
reason we don't coalesce the two). The point is that there is no
redeclaration of yes:
{
int yes = 1;
setsockopt(socket, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof yes);
}
We can use goto around the block, without the problem of jumping
around the initializer into a scope where the identifier is visible:
// bad, and error in C++:
if (condition)
goto label;
int x = 42
label: ;
// Okay: entire scope is bypassed, thanks to closing brace:
if (condition)
goto label;
{
int x = 42;
}
label: ;
The declaration-as-statement is a poorly considered misfeature that
panders to programmers whose primary goal is reducing the number of
braces.
Some people really like reducing the braces though, for some reason;
they are not necessarily "bad" programmers.
There is an implementation of Common Lisp called CLISP whose history
goes back to the 1980s. Its core run time is written in C.
Most of the C files are named with a .d suffix, and are preprocessed
to a .c suffix.
The preprocessor is a simple script called "varbrace" which converts
mixed declaration/statement syntax into C90 syntax with the braces
around the nested scopes.
Go figure.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-19 11:00 +0200 |
| Message-ID | <uebnuo$296h8$1@dont-email.me> |
| In reply to | #175918 |
On 18/09/2023 19:15, Kaz Kylheku wrote:
> On 2023-09-18, David Brown <david.brown@hesbynett.no> wrote:
>>
>> I prefer not to declare any variable until I have a proper
>> initialisation for it.
>
> C90 syntax supports this by allowing nested compound statements to
> introduce declarations.
>
> {
> int yes = 1;
> setsockopt(socket, SOL_SOCKET, SO_KEEPALIVE, &yes, sizeof yes);
> }
>
> This has advantages. We control not only the start of the identifier's
> scope, but also the end.
>
That's all true, but is the OP using C90? I've assumed he is using more
modern C, and the layout defining locals at the start of the function is
an active choice.
I think it is reasonable to assume that people are using at least C99,
if not C11, unless they specifically say they are hobbled to C90.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-23 17:01 +0300 |
| Message-ID | <20230923170155.03ab65af4938de3b9c1e7008@gmail.moc> |
| In reply to | #176011 |
David Brown: > is the OP using C90? I've assumed he is using more modern > C, and the layout defining locals at the start of the > function is an active choice. It is an active choice, which allows me to use C90, not the other way round. -- () 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-23 16:35 +0200 |
| Message-ID | <uemt48$qssi$1@dont-email.me> |
| In reply to | #176246 |
On 23/09/2023 16:01, Anton Shepelev wrote: > David Brown: > >> is the OP using C90? I've assumed he is using more modern >> C, and the layout defining locals at the start of the >> function is an active choice. > > It is an active choice, which allows me to use C90, not the > other way round. > I made a post with multiple reasons why I personally think it is a bad choice - if you have the opportunity, I think it would be interesting to hear why you think differently. You could add to that list your reasons why you think being able to write C90 code is a good thing. (I'm not saying you are wrong, merely that your preferences are different, and I am curious as to why.)
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-23 19:13 +0300 |
| Message-ID | <20230923191325.5e24840b4e13d321f7172551@gmail.moc> |
| In reply to | #176247 |
David Brown: > I made a post with multiple reasons why I personally think > it is a bad choice -- if you have the opportunity, I think > it would be interesting to hear why you think differently. > You could add to that list your reasons why you think > being able to write C90 code is a good thing. (I'm not > saying you are wrong, merely that your preferences are > different, and I am curious as to why.) Yes, I remembered it. Answered five or so minutes ago, but (I fear) not to your satisfaction... -- () 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-25 10:38 +0200 |
| Message-ID | <uerguk$1qrj9$1@dont-email.me> |
| In reply to | #176256 |
On 23/09/2023 18:13, Anton Shepelev wrote: > David Brown: > >> I made a post with multiple reasons why I personally think >> it is a bad choice -- if you have the opportunity, I think >> it would be interesting to hear why you think differently. >> You could add to that list your reasons why you think >> being able to write C90 code is a good thing. (I'm not >> saying you are wrong, merely that your preferences are >> different, and I am curious as to why.) > > Yes, I remembered it. Answered five or so minutes ago, but > (I fear) not to your satisfaction... > It was certainly to my satisfaction - I was looking for your reasons for your choices, not for agreement with /my/ reasons for /my/ choices, and that's what you gave. (Of course, I'd also be quite happy if you read my post and changed your mind to agree with me :-) )
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-23 19:05 +0300 |
| Message-ID | <20230923190523.1f810ae96368b345fe455268@gmail.moc> |
| In reply to | #175909 |
David Brown to Anton Shepelev:
> > I prefer not to mix variable declaration and
> > initialisation, but first to declare my data and then to
> > work with it.
>
> Why? I've seen people give good reasons for this habit,
> and bad reasons for it, so I'm curious as to /your/
> reasons!
First of all, I like the philosophy of this approach, which
brings Wirth's equation:
Algorithms + Data Structures = Programs
down the very bottom, where I separate variables (data) and
operations upon them (algorithms). Some specific reasons
are:
1. The ability to maintain at the start of function body
a TOC-like three-column table with variable name, its
type, and a descriptive comment. Below you mention
your mathematical training, and that is the language
of physics, which reminds of me of the classic papers
by Thelle & Small on loudspeaker modelling, which
begin their analysis by listing all the symbols used
togher with their types (physical units) and
annotations.
2. Upon encountering a new variable, the reader can
glance at the top of function to find its type and
desctiption, whereas intermixed style is requires
scanning the entire text, unless, of course, you count
IDE helper tools, which I do not. Code should read
smooth off a printed page.
3. Interleaved initialisation makes the code visually
ragged and uneven -- to my taste. The declarations
"data" it works with are scatterd all over the place.
4. When maintaining a unified section with declarations
becomes uncomfortable -- it is a natural signal the
function should be split or otherwise simplified.
5. I use `goto' rather intensively to linearise or
flatten unnecessarily nested code. (Deep nesting can
be natural, in which case decreasing it with `goto' is
wrong.)
Bart here has inventively come up with a set of 13 reasons,
in two posts:
http://al.howardknight.net/?ID=155215407800
http://al.howardknight.net/?ID=155215418300
> I prefer not to declare any variable until I have a proper
> initialisation for it. This gives me several advantages :
>
> * As soon as the variable exists, it is valid - there is
> never a point at which code can refer to it without it
> having a proper value.
Indeed, but then the complier should be able to check this
for you, at least with regard to start-of-scope.
> * Variables can often be declared "const". This leads to
> clearer code that is easier to reason about - things
> don't change, and you only have to look at one line to
> see the value that the variable has.
Once you know it is `const', yes.
> For non-const variables, you have to look throughout
> their lifetimes - this is maximally bad if they are
> defined at the top of the function.
If `const' were extended to allow a bare declaration and
then, somewhere below, excactly one assignment, I should be
using it more.
> * Code is easier to write and maintain, and can more
> easily be re-used, copied or re-arranged as you only
> have the one line (definition and initialisation) to
> handle, rather than two separate lines in different
> parts of the function.
Yes, the heavy refactoring of a function is often a two-step
process for me: a. move the code, and then b. move the
declation it depends on. But I prefer to optimise for
reading rather than for writing.
> "Leftovers", such as your "newcap" variable in your
> initial post, are much rarer.
Probably. In the case of `newcap', I thought GCC's -Wall
included the warning about unused variables (and I use
-WError), but it does not.
> * Making new local variables becomes "cheaper" in terms of
> writing the code, and for people reading and
> understanding the code.
Controverisal for me: cheaper in the sense you give, but
dearer me as reader.
> This makes it natural to write a lot of code in "static
> single assignment form" - you write your code as a
> series of expressions, the results of which are assigned
> to const variables and are therefore unchanged within
> their lifetimes. This ties in very well with your
> points 2 and 3 below.
I agree that in general, using variables permanently to
store the value they are first assigned makes for more
readable and less error-prone code. I myself often do it at
work, albeit in a language without a concept `const'. As
the function grows longer, the advantages of combined in-
place declaration and initialisation become more apparent,
and start to outweigh the advantages of the alternative
approach (as I see them).
> I am mathematically trained, and learned a lot of
> programming principles using functional programming
> (though I am decades out of practice at it). I have never
> been entirely comfortable with the idea of changing a
> variable - "x = x + 1"
You do indeed get this feeling in symbolic math. An
equation is not a process, but a statement of fact, although
it may describe a process, as in differential calculus:
dv = a dt
dx = v dt
That said, I distinguish statments of fact (inlcuding
invariants) from statements of action -- executable pieces
of code that change the state of the system.
> Obviously in an imperative language like C, you are going
> to update variables in loops,
Yes -- loops and various accumulators.
> but it is, to me, often better to use new const variables
> than to re-use an existing variable.
Same for me, sans `const'. I reuse the input variable for
return as an experiment in various interpretations of
minimalism. Formally, the function returns a new array, but
from the user perspective and accroding to its name, it
modifies the array, whereas the need to return a potentially
changed pointer is a technicality.
> > if( m != NULL ) a = DATA( m );
> > else a = NULL ;
>
> However, your layout for "if" statements is, IMHO,
> appalling. (Everything here is very much IMHO.)
And I think it precise, concise, and clean. It nicely
emphasizes the structural parts of the `if' operator. If
the exprssions are longer, I use these alternatives:
if( short_condition() ) long_long_long_long_expression ();
else very_long_long_long_long_expression();
if( long_long_long_long_long_long_condition() )
super_long_long_long_long_long_long_long_long_expression() ; else
ultra_long_long_long_long_long_long_long_long_long_expression();
> Anyone who sent in code like that for a code review here
> would be sent back again - I would not even bother telling
> them why, as I would expect every C programmer (in my
> field at least) to have braces in any conditional with an
> "else".
For reasons of safety? To have the same thing expressed
twice -- via indentation and via (redundant) braces?
> I would also expect far better use of white space (though
> I realise that is much more personal style) :
Do you mean vertical spacing?
> void * setlen(void * a, unsigned int len)
> {
> meta_t * m1 = META(a);
> meta_t * m2 = setlen(m1, len);
> if (m2) {
> return DATA(m); /* Ant: did you mean m2 ? */
> } else {
> return NULL;
> }
> }
Several lines with but a curly brace on them -- seems ugly
to me. The placement of curly braces gives me the
impression of something prickly. It also works someone
better for non-curly languates, such as Pascal, but then I
tend to put `begin' on a separate line, too.
I understand the style, however, where /both/ opening and
closing braces are put out of the way, that is:
void * setlen(void * a, unsigned int len) {
meta_t * m1 = META(a);
meta_t * m2 = setlen(m1, len);
if (m2) {
return DATA(m2); }
else {
return NULL; } }
This is consistent, and with transparent intent. I see no
reason in an empty (except for the solitary brace) line
between the function declaraion and definition, although
there must be a line before the declaraiton, to separate the
function the previous one.
> I (almost) always typedef my structs - there's no benefit
> in my code to writing out "struct" on each use. A struct
> type is a type, and writing "struct" (or "union", or
> "enum") when using such types is a distraction from the
> useful code.
Somebody here or elsewhere expressed a preference for
un-#typedef'd structs because they did (or do, pardon my
English?) not conceal the nature of the type. But you are
probably right, for programming deals with complexity by
slicing it into layers of abstraction, in order on each
level to work with the simplest and smallest necessary
interface with the layer below, so that `struct' may be
safely hidden as a detail from a lower layer.
> I'd use better names for "m1" and "m2" if I knew what the
> code was doing :-)
In short, those are metadata pointers, to structures located
at a negative offset from what the end user works with as
the array pointer. You can call them `m_old' and `m_new',
or `m_cur' (-rent) and `m_new'.
> And I would not consider using macros for the "META" and
> "DATA" - inline functions are a far better choice here.
But are they part of C89?
> Occasionally I find it helpful to have a "return variable"
> - typically if there is some kind of epilogue or clean-up
> after the return value is calculated. Normally, however,
> when I have the value to return, I prefer to return it.
Oh, but this is another penchant of mine -- to have a single
exit point from every function.
> Feel free to value or ignore these opinions.
I can do both! I value your comments for their arguments
regardless of whether I decide to follow them or not.
--
() 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-23 18:45 +0100 |
| Message-ID | <uen88d$svtb$1@dont-email.me> |
| In reply to | #176254 |
On 23/09/2023 17:05, Anton Shepelev wrote: >> I am mathematically trained, and learned a lot of >> programming principles using functional programming >> (though I am decades out of practice at it). I have never >> been entirely comfortable with the idea of changing a >> variable - "x = x + 1" > > You do indeed get this feeling in symbolic math. An > equation is not a process, but a statement of fact, although > it may describe a process, as in differential calculus: > > dv = a dt > dx = v dt > > That said, I distinguish statments of fact (inlcuding > invariants) from statements of action -- executable pieces > of code that change the state of the system. This is just an unfortunate consequence of using "=" for assignment. Elsewhere I use "=" in two main ways, neither of them assignment: * To define new names for things, with identities known either at compile-time or before executions starts (eg. define an alias for a type) * To test for equality, which is generally done at runtime But I've also long understood that language syntax is not mathematical notation. For assignments that happen after execution starts, I use ":=". (Using interpreted code run from source, using functions such as eval() and exec() in a dynamic language, or now constexpr(), blurs the line between compile-time and run-time. But in my implementations at least, there is always a compilation step between a source code string, and evaluating that string.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-23 14:24 -0400 |
| Message-ID | <w3GPM.16944$hC28.2371@fx01.iad> |
| In reply to | #176254 |
On 9/23/23 12:05 PM, Anton Shepelev wrote: > First of all, I like the philosophy of this approach, which brings > Wirth's equation: Algorithms + Data Structures = Programs One thing to point out, "Data Structures" doesn't mean "All Variables in the program", since "Algorithms", by their nature, tend to create temporary "internal" state which is part of the algorithm, and not Data Structures. When your function implements an "Algorithm", the "Data Structures" it is working on are the function arguments (or possibly globals) and the local variables are just the temporary state used to implement the algorithm.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-24 17:05 +0000 |
| Message-ID | <T%ZPM.165865$Hih7.7882@fx11.iad> |
| In reply to | #176254 |
Anton Shepelev <anton.txt@gmail.moc> writes:
>David Brown to Anton Shepelev:
>
>> > I prefer not to mix variable declaration and
>> > initialisation, but first to declare my data and then to
>> > work with it.
>>
>> Why? I've seen people give good reasons for this habit,
>> and bad reasons for it, so I'm curious as to /your/
>> reasons!
>
>First of all, I like the philosophy of this approach, which
>brings Wirth's equation:
>
> Algorithms + Data Structures = Programs
>
>down the very bottom, where I separate variables (data) and
>operations upon them (algorithms). Some specific reasons
>are:
>
> 1. The ability to maintain at the start of function body
> a TOC-like three-column table with variable name, its
> type, and a descriptive comment.
Some of the older C coding guidelines were matched by functionality
in vi, such as using '[[' to move to the start of the function
(to examine that 'TOC-like' list) and '``' to return to former
line.
Function definition syntax like:
const char *
get_string(const char *, size_t)
{
}
Allowed searches using '/^get_string' to find a named function definition.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.moc> |
|---|---|
| Date | 2023-09-24 23:26 +0300 |
| Message-ID | <20230924232618.0b5bef5a35b2fa07718a09a5@gmail.moc> |
| In reply to | #176312 |
Scott Lurndal to Anton Shepelev:
> > The ability to maintain at the start of function body a
> > TOC-like three-column table with variable name, its
> > type, and a descriptive comment.
>
> Some of the older C coding guidelines were matched by
> functionality in vi, such as using '[[' to move to the
> start of the function (to examine that 'TOC-like' list)
> and '``' to return to former line.
They still there, according do the Vim manual:
The "]" and "[" commands stop at the '{' or '}' in the
first column. This is useful to find the start or end of
a function in a C program. Note that the first character
of the command determines the search direction and the
second character the type of brace found.
`` To the position before the latest jump, or where the
last "m'" or "m`" command was given.
> Function definition syntax like:
>
> const char *
> get_string(const char *, size_t)
> {
> }
>
> Allowed searches using '/^get_string' to find a named
> function definition.
Good idea. Now I have to search for the first occurence of
`get_string('. Another possible trick it to put a space
between the function name and the opeining parethesis in the
definition, but not in invocations.
--
() 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-25 08:43 +0200 |
| Message-ID | <uera6l$1pr35$1@dont-email.me> |
| In reply to | #176254 |
On 23/09/2023 18:05, Anton Shepelev wrote:
> David Brown to Anton Shepelev:
>
>>> I prefer not to mix variable declaration and
>>> initialisation, but first to declare my data and then to
>>> work with it.
>>
>> Why? I've seen people give good reasons for this habit,
>> and bad reasons for it, so I'm curious as to /your/
>> reasons!
>
> First of all, I like the philosophy of this approach, which
> brings Wirth's equation:
>
> Algorithms + Data Structures = Programs
>
> down the very bottom, where I separate variables (data) and
> operations upon them (algorithms).
Wirth's languages tended to have strong separation of data and code.
But remember, the focus of his languages were on two things - being good
for teaching and learning, and being simple to implement (when
optimisation is not important). C does not fit into either category.
Nor do other major languages used for "real" programming. (Of course
there are "real" programs written in Pascal - but for the most part,
you'll see Wirth's languages in academic institutions, not in the
software industry).
Also remember that Wirth wrote that (and languages like Pascal) some
40-50 years ago. We've learned a lot since then, and developed better
coding techniques over time. Wirth's most modern language, Oberon, is
object oriented - data and code are much more integrated and mixed in
such code.
> Some specific reasons
> are:
>
> 1. The ability to maintain at the start of function body
> a TOC-like three-column table with variable name, its
> type, and a descriptive comment. Below you mention
> your mathematical training, and that is the language
> of physics, which reminds of me of the classic papers
> by Thelle & Small on loudspeaker modelling, which
> begin their analysis by listing all the symbols used
> togher with their types (physical units) and
> annotations.
I can see that putting the variables at the start of the function lets
you make a list like that. I cannot, however, see any advantage of
having such a list. Local variables are temporary - they are just there
to hold intermediary results and give convenient names to things so that
it's easier to see what is going on. A list of variables does not aid
understanding of a function - rather, it detracts from it because you
are splitting the information (how the variable is declared, and how it
is used) into two separate parts.
>
> 2. Upon encountering a new variable, the reader can
> glance at the top of function to find its type and
> desctiption, whereas intermixed style is requires
> scanning the entire text, unless, of course, you count
> IDE helper tools, which I do not. Code should read
> smooth off a printed page.
No, you are completely wrong here.
With your style, the reader encountering a new variable has to deal with
two wildly separate parts of the text - the definition at the start of
the function, and the use of the variable in the code. It is particular
bad for large functions or when you have a small screen or window (this
can be the case when you are debugging, for example), and you have to
scroll around.
With my style, everything is there clearly in one spot. No scanning or
searching is needed - it's all there on the same line or two.
>
> 3. Interleaved initialisation makes the code visually
> ragged and uneven -- to my taste. The declarations
> "data" it works with are scatterd all over the place
I write code, I don't draw pictures. The aim is to make things clear to
human programmers reading the code, not to match the aesthetic tastes of
art critics in a gallery. The visual appearance of code matters if -
and only if - it affects the readability.
.
>
> 4. When maintaining a unified section with declarations
> becomes uncomfortable -- it is a natural signal the
> function should be split or otherwise simplified.
That is always the case for functions, no matter the style used.
The reality, however, is often different. Many functions start off
small, but grow bigger than desirable as the code evolves. Your style
gets more and more tedious, uncomfortable, and error-prone, to a much
greater extent than defining local variables as an when they are needed.
This is exasperated by C90 styles from the days of weaker compilers and
no "inline" functions, when people wrote longer functions and hideous
function-like macros because splitting up functions made code slower.
>
> 5. I use `goto' rather intensively to linearise or
> flatten unnecessarily nested code. (Deep nesting can
> be natural, in which case decreasing it with `goto' is
> wrong.)
Extensive use of "goto" is a strong indicator of poorly structured code,
functions that are far too long, or a programmer doing
"micro-optimisations" that are better left to the compiler. (There are
some types of code for which "goto" makes things clearer, but I think
they are rare.)
And I would say that defining variables at the top of the function is
the worst choice you could have if you use "goto" often. It is better
to consider labelled parts of the function as "sub-functions", each with
their own local variables defined and initialised within their local areas.
>
> Bart here has inventively come up with a set of 13 reasons,
> in two posts:
>
> http://al.howardknight.net/?ID=155215407800
> http://al.howardknight.net/?ID=155215418300
>
I've heard plenty of reasons before, including at least some of Bart's,
but I was interested in /your/ reasons. (Thank you for giving them.)
>> I prefer not to declare any variable until I have a proper
>> initialisation for it. This gives me several advantages :
>>
>> * As soon as the variable exists, it is valid - there is
>> never a point at which code can refer to it without it
>> having a proper value.
>
> Indeed, but then the complier should be able to check this
> for you, at least with regard to start-of-scope.
Usually the compiler can, yes. (And if you for some reason have to work
with poorer quality compilers, you can use additional linters or other
compilers for such static checks.) But while it's easy for a compiler
to jump around the code, I'd rather human programmers did not have to do
so. That's the focus here - the /human/ knows that the variable is
always valid. They don't have to wonder if it has been set yet, no
matter where they look in the code.
>
>> * Variables can often be declared "const". This leads to
>> clearer code that is easier to reason about - things
>> don't change, and you only have to look at one line to
>> see the value that the variable has.
>
> Once you know it is `const', yes.
>
>> For non-const variables, you have to look throughout
>> their lifetimes - this is maximally bad if they are
>> defined at the top of the function.
>
> If `const' were extended to allow a bare declaration and
> then, somewhere below, excactly one assignment, I should be
> using it more.
From what you've written so far, I don't see any significant features
of your style that could not be accomplished equally well by comments.
Why not write (formatted however you prefer) :
// int sum_sq - holds the sum of the squares
at the top of the function, and then
const int sum_sq = x * x + y * y;
in the code?
Or even use doxygen format (with "\var")? You only need to document the
important local variables that help the reader understand the code, not
the little ones whose use is obvious.
>
>> * Code is easier to write and maintain, and can more
>> easily be re-used, copied or re-arranged as you only
>> have the one line (definition and initialisation) to
>> handle, rather than two separate lines in different
>> parts of the function.
>
> Yes, the heavy refactoring of a function is often a two-step
> process for me: a. move the code, and then b. move the
> declation it depends on. But I prefer to optimise for
> reading rather than for writing.
>
So do I - that's why I avoid your style of coding. I realise writing
style is often very personal - but remember that /reading/ is much less
personal. /You/ may find it easier to read ancient Greek than English,
but most programmers do not. Similarly, "optimising for reading" must
concern itself with /other/ programmers. Imagine someone who learned C
a mere 20 years ago and reads everything on screens, rather than someone
who sees C and fanfold paper printouts as a step up from FORTRAN and
punched cards.
Even when I had to use C90 I preferred to be able to declare variables
inside code blocks. I rarely made artificial blocks just for variable
declarations, but used natural blocks for conditionals, loops, etc.
>> "Leftovers", such as your "newcap" variable in your
>> initial post, are much rarer.
>
> Probably. In the case of `newcap', I thought GCC's -Wall
> included the warning about unused variables (and I use
> -WError), but it does not.
>
It does warn about unused variables - there must be some other reason
why you did not get a warning.
But do not use compiler warnings as a crutch for poor development
practices and coding styles. They prevent accidents (we all make
mistakes sometimes). They are a complement and addition to other
practices that encourage good coding - they don't replace good design,
good code layout, re-reading your own code, etc.
>> * Making new local variables becomes "cheaper" in terms of
>> writing the code, and for people reading and
>> understanding the code.
>
> Controverisal for me: cheaper in the sense you give, but
> dearer me as reader.
The sense I gave /was/ for people reading the code. Again, I think you
are assuming that "readers" are people with the same habits and
practices as yourself, and that is not normally the case for any
programmer - much less a programmer using a decades-outdated style.
Local variables are not merely "cheap" from a compilation viewpoint -
they are in most cases free. So whether you are writing code where
efficiency is not top priority (most code), or writing
efficiency-critical code, extra local variables are free. Thus there is
nothing to stop you using them to make code clearer.
>
>> This makes it natural to write a lot of code in "static
>> single assignment form" - you write your code as a
>> series of expressions, the results of which are assigned
>> to const variables and are therefore unchanged within
>> their lifetimes. This ties in very well with your
>> points 2 and 3 below.
>
> I agree that in general, using variables permanently to
> store the value they are first assigned makes for more
> readable and less error-prone code. I myself often do it at
> work, albeit in a language without a concept `const'. As
> the function grows longer, the advantages of combined in-
> place declaration and initialisation become more apparent,
> and start to outweigh the advantages of the alternative
> approach (as I see them).
If you agree with that, what possible advantages do you see from
declaring these "permanent" variables at the start of the function? All
you are doing is introducing a needless separation, forcing readers to
look in two places in the code to see what is happening (one for the
type, one for the value.
>
>> I am mathematically trained, and learned a lot of
>> programming principles using functional programming
>> (though I am decades out of practice at it). I have never
>> been entirely comfortable with the idea of changing a
>> variable - "x = x + 1"
>
> You do indeed get this feeling in symbolic math. An
> equation is not a process, but a statement of fact, although
> it may describe a process, as in differential calculus:
>
> dv = a dt
> dx = v dt
>
> That said, I distinguish statments of fact (inlcuding
> invariants) from statements of action -- executable pieces
> of code that change the state of the system.
>
Yes, assignment in an imperative language is different from equality in
mathematics. But when I can write my statements of action in a way that
also makes them statements of fact, the result is clearer code less open
to misinterpretation by readers or mistakes by the writer (or maintainers).
>> Obviously in an imperative language like C, you are going
>> to update variables in loops,
>
> Yes -- loops and various accumulators.
>
>> but it is, to me, often better to use new const variables
>> than to re-use an existing variable.
>
> Same for me, sans `const'. I reuse the input variable for
> return as an experiment in various interpretations of
> minimalism. Formally, the function returns a new array, but
> from the user perspective and accroding to its name, it
> modifies the array, whereas the need to return a potentially
> changed pointer is a technicality.
>
>>> if( m != NULL ) a = DATA( m );
>>> else a = NULL ;
>>
>> However, your layout for "if" statements is, IMHO,
>> appalling. (Everything here is very much IMHO.)
>
> And I think it precise, concise, and clean. It nicely
> emphasizes the structural parts of the `if' operator.
No (IMHO). It shouts - that's due to use of all-caps macro names. It
reads "NULL", "DATA", "NULL", and then you have to look closely to see
the rest of it.
It fails to show the structure of the "if" - there are no blocks, and no
indentation to make it all obvious to the reader. Maintenance is harder
(imagine adding more statements to the conditional parts), and the use
of macros within unblocked conditional statements compounds this.
It provides no visual layout or separation of the "then" and "else"
parts. It provides no space for comments. It is a mess if the "then"
or "else" parts need to be longer - more statements, or longer
expressions, or if the conditional part is bigger.
It adds unhelpful extra spacing, more reminiscent of FORTRAN fixed
column layouts than modern coding.
It adds an unhelpful extra comparison inside the conditional - it takes
very little familiarity with C to know that "if (m)", where "m" is a
pointer, checks for non-null pointers. Putting that in explicitly adds
nothing, but leaves readers wondering why.
Do not mistake your own familiarity with a particular layout as meaning
it is "precise" or "clean". (I know everyone, including me at least as
much as anyone else, /does/ make that mistake.)
> If
> the exprssions are longer, I use these alternatives:
>
> if( short_condition() ) long_long_long_long_expression ();
> else very_long_long_long_long_expression();
>
> if( long_long_long_long_long_long_condition() )
> super_long_long_long_long_long_long_long_long_expression() ; else
> ultra_long_long_long_long_long_long_long_long_long_expression();
>
>> Anyone who sent in code like that for a code review here
>> would be sent back again - I would not even bother telling
>> them why, as I would expect every C programmer (in my
>> field at least) to have braces in any conditional with an
>> "else".
>
> For reasons of safety?
Yes. Safety, readability, maintainability.
> To have the same thing expressed
> twice -- via indentation and via (redundant) braces?
Yes - for safety, readability, and maintainability.
>
>> I would also expect far better use of white space (though
>> I realise that is much more personal style) :
>
> Do you mean vertical spacing?
Yes, in this case. I also find your horizontal spacing choices put all
the space in the wrong places. It's like suddenly
finding extra spaces, or crushedupwords withnospaces in writing. It's
possible to read it, but it's unnecessarily difficult. The more
cognitive effort it takes to interpret the layout of the code, the less
the reader has left to understand the /meaning/ of the code.
>
>> void * setlen(void * a, unsigned int len)
>> {
>> meta_t * m1 = META(a);
>> meta_t * m2 = setlen(m1, len);
>> if (m2) {
>> return DATA(m); /* Ant: did you mean m2 ? */
>> } else {
>> return NULL;
>> }
>> }
>
> Several lines with but a curly brace on them -- seems ugly
> to me.
That's the way the language layout goes. If you don't like braces, you
are never going to be happy with C !
> The placement of curly braces gives me the
> impression of something prickly. It also works someone
> better for non-curly languates, such as Pascal, but then I
> tend to put `begin' on a separate line, too.
I follow the same pattern for Pascal code layout (with begin/end instead
of braces, obviously).
>
> I understand the style, however, where /both/ opening and
> closing braces are put out of the way, that is:
>
> void * setlen(void * a, unsigned int len) {
> meta_t * m1 = META(a);
> meta_t * m2 = setlen(m1, len);
> if (m2) {
> return DATA(m2); }
> else {
> return NULL; } }
>
The style I use is known as "The one true brace style". It is very
simple - open braces occur only at the end of a line, and are followed
by an indent level. Close braces occur only at the beginning of a line,
and have an outdent. Everything is very simple, clear and consistent.
Do you use source code control systems (Git, svn, etc.)? A good layout
like mine makes it hugely easier to work with these tools, and have your
changes (especially small changes) show clearly where the workings of
the code change rather than unhelpful changes to the layout.
> This is consistent, and with transparent intent. I see no
> reason in an empty (except for the solitary brace) line
> between the function declaraion and definition, although
> there must be a line before the declaraiton, to separate the
> function the previous one.
Your layout here is certainly a big step forward from your original
cramped and unclear style. It's arguably half-way to being good!
>
>> I (almost) always typedef my structs - there's no benefit
>> in my code to writing out "struct" on each use. A struct
>> type is a type, and writing "struct" (or "union", or
>> "enum") when using such types is a distraction from the
>> useful code.
>
> Somebody here or elsewhere expressed a preference for
> un-#typedef'd structs because they did (or do, pardon my
> English?) not conceal the nature of the type.
Some people prefer that. I think that if you need to keep adding
"struct" to the types you use in declarations, you haven't picked good
enough names for the types.
> But you are
> probably right, for programming deals with complexity by
> slicing it into layers of abstraction, in order on each
> level to work with the simplest and smallest necessary
> interface with the layer below, so that `struct' may be
> safely hidden as a detail from a lower layer.
>
>> I'd use better names for "m1" and "m2" if I knew what the
>> code was doing :-)
>
> In short, those are metadata pointers, to structures located
> at a negative offset from what the end user works with as
> the array pointer. You can call them `m_old' and `m_new',
> or `m_cur' (-rent) and `m_new'.
>
>> And I would not consider using macros for the "META" and
>> "DATA" - inline functions are a far better choice here.
>
> But are they part of C89?
I would not consider using C89/C90, unless it was absolutely
unavoidable. (I've occasionally had to update code I wrote some 20+
years ago, forcing me to go back to C90. Ugh!)
>
>> Occasionally I find it helpful to have a "return variable"
>> - typically if there is some kind of epilogue or clean-up
>> after the return value is calculated. Normally, however,
>> when I have the value to return, I prefer to return it.
>
> Oh, but this is another penchant of mine -- to have a single
> exit point from every function.
>
That is a common rule. It is, IMHO, a mistake when taken too far. It
is also usually a bad idea to have lots of returns scattered around a
big function.
>> Feel free to value or ignore these opinions.
>
> I can do both! I value your comments for their arguments
> regardless of whether I decide to follow them or not.
>
I appreciate the conversation, and hearing the thoughts behind
preferences and habits.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-25 11:51 +0100 |
| Message-ID | <ueronc$1sd54$1@dont-email.me> |
| In reply to | #176338 |
On 25/09/2023 07:43, David Brown wrote: > On 23/09/2023 18:05, Anton Shepelev wrote: >> 2. Upon encountering a new variable, the reader can >> glance at the top of function to find its type and >> desctiption, whereas intermixed style is requires >> scanning the entire text, unless, of course, you count >> IDE helper tools, which I do not. Code should read >> smooth off a printed page. > > No, you are completely wrong here. > > With your style, the reader encountering a new variable has to deal with > two wildly separate parts of the text - the definition at the start of > the function, and the use of the variable in the code. It is particular > bad for large functions or when you have a small screen or window (this > can be the case when you are debugging, for example), and you have to > scroll around. I've spent a few days working with C codebases where I have exactly that problem: figuring out the details of a typedef, struct, enum, global variable, function or macro, used in a function, which might be declared not only 100s or 1000s of lines earlier, but in one of a dozen include files. So yes, that happens anyway, but on a big scale. I wish it WAS only at the start of function that I have to look! To go back to one of the points I made in those links: suppose I define a typedef say at module scope to be shared by functions 35, 62 and 78 of 100 functions in that module. Where should I place that typedef: before the definition of function 1, or immediately before function 35 since that is where it is first used? Because I rarely see functions, global variables and typedefs mixed up like that. Maybe it's the next big thing. Anyway, it is that segregation that I like to see within a function too.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-25 15:40 +0200 |
| Message-ID | <ues2jo$1uh7s$1@dont-email.me> |
| In reply to | #176356 |
On 25/09/2023 12:51, Bart wrote: > On 25/09/2023 07:43, David Brown wrote: >> On 23/09/2023 18:05, Anton Shepelev wrote: > >>> 2. Upon encountering a new variable, the reader can >>> glance at the top of function to find its type and >>> desctiption, whereas intermixed style is requires >>> scanning the entire text, unless, of course, you count >>> IDE helper tools, which I do not. Code should read >>> smooth off a printed page. >> >> No, you are completely wrong here. >> >> With your style, the reader encountering a new variable has to deal >> with two wildly separate parts of the text - the definition at the >> start of the function, and the use of the variable in the code. It is >> particular bad for large functions or when you have a small screen or >> window (this can be the case when you are debugging, for example), and >> you have to scroll around. > > I've spent a few days working with C codebases where I have exactly that > problem: figuring out the details of a typedef, struct, enum, global > variable, function or macro, used in a function, which might be declared > not only 100s or 1000s of lines earlier, but in one of a dozen include > files. > > So yes, that happens anyway, but on a big scale. I wish it WAS only at > the start of function that I have to look! In all code, beyond "Hello, world!" programs, you will need to look in different parts of the code base when you need more details. There is no escape from that, in any language. So you have to do what you can to reduce the effort involved here. (And not everyone is good at that - please do not blame /me/ for sub-optimal code organisations in some project you have found.) Putting your local variable definitions at the point where they have an initial value, preferably keeping them const, and using minimal reasonable scopes, will all reduce this effort. But that is only part of the picture. Use clear header files containing only the code necessary, with corresponding implementation files that make everything "static" unless the variable/const/function is "exported" in the header file. Divide the code into multiple files, in logical partitions. Use multiple source directories if the project is big enough. Use good names for everything - files, types, functions, data, etc. Smaller scope items can have shorter names, bigger scope items need more descriptive names. Use the best tools you can get hold of - use good IDE's or editors. Document the code as well as you reasonably can, based on appropriate needs for the project. Preferably this should involve automated code documentation tools like doxygen to minimise the risk of code and documentation mismatches, to reduce the effort involved in the documentation (writing documentation is rarely the fun part of development!), and to generate caller/callee/include graphs, cross-references, etc. Keep a good structure and clean interfaces at all levels - divide and conquer. (Using good tools almost invariably means using well established languages - not necessarily C, but not obscure or rare languages.) So I don't in any way claim that using proper local variables, defined when they are used, solves all software development challenges. But it is /part/ of the solution. > > To go back to one of the points I made in those links: (I haven't read your links.) > suppose I define > a typedef say at module scope to be shared by functions 35, 62 and 78 of > 100 functions in that module. > > Where should I place that typedef: before the definition of function 1, > or immediately before function 35 since that is where it is first used? > That's a stupid question. Don't have 100 functions in your module. In your 20 function module, if your typedef is used in functions 3, 9 and 17, then it's worth considering if the order of functions in the module makes sense. Assuming it does, then common practice would likely be placing it near the start of the module. (If the type is part of the interface to exported code or data, then of course it must be placed in the header file.) > Because I rarely see functions, global variables and typedefs mixed up > like that. Maybe it's the next big thing. > "global variables" - variables that are exported from a module - should be declared in a header file, and are usually then defined at the start of the implementation file. (Generally, heavy use of global variables is frowned upon - they can give too tight coupling between different modules.) Static file-scope data is often defined near the start of a module, though I am quite happy to define it just before the functions that use it, especially if there are only one or two and it is effectively local state for the implementation. > Anyway, it is that segregation that I like to see within a function too. I know you do. You and Anton are far from alone in this. But I think you both write poorer code because of it. (And if you disagree with the reasons I gave, fair enough - it's your code, not mine.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-25 18:56 +0100 |
| Message-ID | <ueshl5$21lmm$1@dont-email.me> |
| In reply to | #176363 |
On 25/09/2023 14:40, David Brown wrote: > On 25/09/2023 12:51, Bart wrote: >> suppose I define a typedef say at module scope to be shared by >> functions 35, 62 and 78 of 100 functions in that module. >> >> Where should I place that typedef: before the definition of function >> 1, or immediately before function 35 since that is where it is first >> used? >> > > That's a stupid question. Don't have 100 functions in your module. Huh? I didn't realise that was that controversial. I don't actually know how many functions I have per module, I've never counted! But I've counted now, and my projects have 20-40 functions/module on average. Library modules tend to have more (up to 100), and maximum was 220 functions in one file (handler functions for bytecode, and similar modules where there is some sort of N-way dispatch going on). Among C projects (not mine), the first couple I tried were 33 functions average, 100 max (Lua), and 26 average/200 max (BBX). LibJPEG averaged 9, but that also uses 70 files for a JPEG-handling library, so it's rather spread out. You can implement JPEG encoders and decoders in about one 1Kloc file each. BTW sql.c (one-file sqlite3.c plus enough code to make a working app), had 2300 functions on one file, with one of those functions being 7000 lines. > In your 20 function module So 20 is reasonable but not 100? OK. I am aware of the line counts of my modules, and those probably average 1000 lines per module, with a max of 3-5Kloc. I really don't think it's that critical. Is there a limit on how many entries in one database before you have to split it up? Or how many files in one folder? The entries belong together!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-25 11:03 -0700 |
| Message-ID | <uesi26$21hbl$7@dont-email.me> |
| In reply to | #176376 |
On 9/25/2023 10:56 AM, Bart wrote: > On 25/09/2023 14:40, David Brown wrote: >> On 25/09/2023 12:51, Bart wrote: > >>> suppose I define a typedef say at module scope to be shared by >>> functions 35, 62 and 78 of 100 functions in that module. >>> >>> Where should I place that typedef: before the definition of function >>> 1, or immediately before function 35 since that is where it is first >>> used? >>> >> >> That's a stupid question. Don't have 100 functions in your module. > > Huh? I didn't realise that was that controversial. I don't actually know > how many functions I have per module, I've never counted! I think there is a complexity rule is MISRA that talks about this... > > But I've counted now, and my projects have 20-40 functions/module on > average. Library modules tend to have more (up to 100), and maximum was > 220 functions in one file (handler functions for bytecode, and similar > modules where there is some sort of N-way dispatch going on). > > Among C projects (not mine), the first couple I tried were 33 functions > average, 100 max (Lua), and 26 average/200 max (BBX). > > LibJPEG averaged 9, but that also uses 70 files for a JPEG-handling > library, so it's rather spread out. You can implement JPEG encoders and > decoders in about one 1Kloc file each. > > BTW sql.c (one-file sqlite3.c plus enough code to make a working app), > had 2300 functions on one file, with one of those functions being 7000 > lines. > >> In your 20 function module > > So 20 is reasonable but not 100? OK. > > I am aware of the line counts of my modules, and those probably average > 1000 lines per module, with a max of 3-5Kloc. > > I really don't think it's that critical. Is there a limit on how many > entries in one database before you have to split it up? Or how many > files in one folder? The entries belong together! >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-25 19:53 +0100 |
| Message-ID | <ueskug$22af7$1@dont-email.me> |
| In reply to | #176377 |
On 25/09/2023 19:03, Chris M. Thomasson wrote: > On 9/25/2023 10:56 AM, Bart wrote: >> On 25/09/2023 14:40, David Brown wrote: >>> On 25/09/2023 12:51, Bart wrote: >> >>>> suppose I define a typedef say at module scope to be shared by >>>> functions 35, 62 and 78 of 100 functions in that module. >>>> >>>> Where should I place that typedef: before the definition of function >>>> 1, or immediately before function 35 since that is where it is first >>>> used? >>>> >>> >>> That's a stupid question. Don't have 100 functions in your module. >> >> Huh? I didn't realise that was that controversial. I don't actually >> know how many functions I have per module, I've never counted! > > I think there is a complexity rule is MISRA that talks about this... Are there are also rules about how many lines in a function, and how many modules in a program? Minimising one will increase the number of functions, and minimising the number of functions per module will increase the number of modules. Further, there will be more complexity due to interactions or interfaces between functions and between modules being exposed, that could have been kept private.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-25 11:55 -0700 |
| Message-ID | <uesl39$22ard$1@dont-email.me> |
| In reply to | #176379 |
On 9/25/2023 11:53 AM, Bart wrote: > On 25/09/2023 19:03, Chris M. Thomasson wrote: >> On 9/25/2023 10:56 AM, Bart wrote: >>> On 25/09/2023 14:40, David Brown wrote: >>>> On 25/09/2023 12:51, Bart wrote: >>> >>>>> suppose I define a typedef say at module scope to be shared by >>>>> functions 35, 62 and 78 of 100 functions in that module. >>>>> >>>>> Where should I place that typedef: before the definition of >>>>> function 1, or immediately before function 35 since that is where >>>>> it is first used? >>>>> >>>> >>>> That's a stupid question. Don't have 100 functions in your module. >>> >>> Huh? I didn't realise that was that controversial. I don't actually >>> know how many functions I have per module, I've never counted! >> >> I think there is a complexity rule is MISRA that talks about this... > > Are there are also rules about how many lines in a function, and how > many modules in a program? > > Minimising one will increase the number of functions, and minimising the > number of functions per module will increase the number of modules. > > Further, there will be more complexity due to interactions or interfaces > between functions and between modules being exposed, that could have > been kept private. Fwiw, here the documentation that I am referring to: https://www.stroustrup.com/JSF-AV-rules.pdf
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-25 20:08 +0100 |
| Message-ID | <ueslrg$22af7$2@dont-email.me> |
| In reply to | #176380 |
On 25/09/2023 19:55, Chris M. Thomasson wrote:
> On 9/25/2023 11:53 AM, Bart wrote:
>> On 25/09/2023 19:03, Chris M. Thomasson wrote:
>>> On 9/25/2023 10:56 AM, Bart wrote:
>>>> On 25/09/2023 14:40, David Brown wrote:
>>>>> On 25/09/2023 12:51, Bart wrote:
>>>>
>>>>>> suppose I define a typedef say at module scope to be shared by
>>>>>> functions 35, 62 and 78 of 100 functions in that module.
>>>>>>
>>>>>> Where should I place that typedef: before the definition of
>>>>>> function 1, or immediately before function 35 since that is where
>>>>>> it is first used?
>>>>>>
>>>>>
>>>>> That's a stupid question. Don't have 100 functions in your module.
>>>>
>>>> Huh? I didn't realise that was that controversial. I don't actually
>>>> know how many functions I have per module, I've never counted!
>>>
>>> I think there is a complexity rule is MISRA that talks about this...
>>
>> Are there are also rules about how many lines in a function, and how
>> many modules in a program?
>>
>> Minimising one will increase the number of functions, and minimising
>> the number of functions per module will increase the number of modules.
>>
>> Further, there will be more complexity due to interactions or
>> interfaces between functions and between modules being exposed, that
>> could have been kept private.
>
> Fwiw, here the documentation that I am referring to:
>
> https://www.stroustrup.com/JSF-AV-rules.pdf
That paragraph is in danger of breaching its own rule.
Look at this line from Lua sources:
luaC_barrier(L, clCvalue(s2v(L->ci->func.p)), fr);
(It's of dozens of instances causing problem for my compiler.)
It'a part of function of only 9 lines. It all seems simple enough. But
exactly is it doing?
It turns out those are macros not functions. A preprocessed version of
that line is:
((((fr)->tt_)&(1<<6))?(((((((&((((union
GCUnion*)(((((&(L->ci->func.p)->val))->value_).gc))))->cl.c))))->marked)&((1<<(5))))&&((((((fr)->value_).gc))->marked)&(((1<<(3))|(1<<(4))))))?luaC_barrier_(L,(&(((union
GCUnion*)((((&((((union
GCUnion*)(((((&(L->ci->func.p)->val))->value_).gc))))->cl.c))))))->gc)),(&(((union
GCUnion*)(((((fr)->value_).gc))))->gc))):((void)((0)))):((void)((0))));
This what *I* call complex, even though it is only one line.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-25 21:29 +0200 |
| Message-ID | <uesn2u$22nob$1@dont-email.me> |
| In reply to | #176379 |
On 25/09/2023 20:53, Bart wrote: > On 25/09/2023 19:03, Chris M. Thomasson wrote: >> On 9/25/2023 10:56 AM, Bart wrote: >>> On 25/09/2023 14:40, David Brown wrote: >>>> On 25/09/2023 12:51, Bart wrote: >>> >>>>> suppose I define a typedef say at module scope to be shared by >>>>> functions 35, 62 and 78 of 100 functions in that module. >>>>> >>>>> Where should I place that typedef: before the definition of >>>>> function 1, or immediately before function 35 since that is where >>>>> it is first used? >>>>> >>>> >>>> That's a stupid question. Don't have 100 functions in your module. >>> >>> Huh? I didn't realise that was that controversial. I don't actually >>> know how many functions I have per module, I've never counted! >> >> I think there is a complexity rule is MISRA that talks about this... > I am pretty sure there is no such rule. I can't see it in my copy of MISRA C 2012 (though I don't claim to be very familiar with the document, so I might have missed something). > Are there are also rules about how many lines in a function, and how > many modules in a program? There is the concept of "Cyclomatic complexity" (<https://en.wikipedia.org/wiki/Cyclomatic_complexity>) which suggests that overly complex functions become impossible to test or even to fully comprehend. > > Minimising one will increase the number of functions, and minimising the > number of functions per module will increase the number of modules. > There can certainly be tradeoffs, yes. Sometimes splitting things up gives better refactorisation and more code reuse, reducing the overall size. But the idea is to deal with manageable chunks at each level. If you are having trouble finding information you need, you have probably chosen the splits poorly - that could mean you have too many divisions, or divisions in the wrong places, as well as possibly meaning your parts are too big. It could also mean that you are looking for too much detail at an inappropriate level - maybe knowing all the details of a type or a function isn't actually important in order to use it correctly. > Further, there will be more complexity due to interactions or interfaces > between functions and between modules being exposed, that could have > been kept private. That can indeed be a factor. That is one of the reasons why I can't give any fixed answers. But if you tell me you have 100 functions in a module, with use of an important type scattered randomly amongst them, and it's hard to know where to put the type definition - then my first guess is the module is too big. I might change that opinion when I know details of it and why the code structure is this way, but that's my initial reaction.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web