Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #87753 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2022-12-08 12:31 +0000 |
| Last post | 2023-01-04 00:22 -0800 |
| Articles | 20 on this page of 333 — 29 participants |
Back to article view | Back to comp.lang.c++
Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-08 12:31 +0000
Re: Overuse of 'auto' Bo Persson <bo@bo-persson.se> - 2022-12-08 15:25 +0100
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-08 15:48 +0000
Re: Overuse of 'auto' Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-12-08 19:29 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-09 15:52 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-09 12:52 +0000
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-09 05:03 -0800
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-09 14:15 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 06:59 +0000
Re: Overuse of 'auto' Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-12-17 16:53 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:32 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-08 07:59 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-09 12:56 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-09 07:57 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-09 17:44 +0000
Re: Overuse of 'auto' Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2022-12-09 21:01 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-09 20:47 +0000
Re: Overuse of 'auto' Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2022-12-10 14:48 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-10 21:52 +0000
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-11 00:29 +0100
Re: Overuse of 'auto' Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> - 2022-12-11 14:37 +0100
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-12 09:35 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-11 16:42 +0100
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-09 13:07 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 07:14 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-12 08:54 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 11:31 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-12 16:11 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 15:59 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-12 17:17 +0000
Re: Overuse of 'auto' Ike Naar <ike@sdf.org> - 2022-12-12 22:02 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-12 22:41 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-12 16:00 -0800
Re: Overuse of 'auto' James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-13 02:48 -0500
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 00:03 -0800
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-13 14:39 +0200
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-13 14:10 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-13 14:59 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 13:07 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 08:24 +0000
Re: Overuse of 'auto' Udo Steinbach <trashcan@udoline.de> - 2022-12-14 17:50 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-14 17:13 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-14 20:01 +0200
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-14 18:12 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-12 10:25 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 08:32 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-13 01:11 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-13 14:31 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 13:42 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-13 09:42 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 10:20 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-13 11:10 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-13 15:58 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 06:23 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 07:36 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 09:43 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 12:19 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 16:24 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:35 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 14:11 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-14 12:17 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-15 08:53 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-16 21:41 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-17 15:34 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-17 13:27 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-17 13:32 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:58 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 07:46 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 14:55 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:24 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 22:03 +0200
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-19 20:38 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 22:54 +0200
Re: Overuse of 'auto' Tony Oliver <guinness.tony@gmail.com> - 2022-12-19 16:38 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 19:18 -0800
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-20 14:51 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 08:23 +0100
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-20 17:52 +0100
Re: Overuse of 'auto' "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-20 17:56 +0100
Re: Overuse of 'auto' Ralf Goertz <me@myprovider.invalid> - 2022-12-21 11:22 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 14:05 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:37 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 19:25 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:09 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:32 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 13:49 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 14:28 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 15:49 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 18:33 +0100
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-20 09:45 -0800
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-20 20:29 +0200
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 10:26 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 15:40 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 15:58 +0000
Re: Overuse of 'auto' Richard Damon <Richard@Damon-Family.org> - 2022-12-21 11:12 -0500
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 17:16 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-21 17:22 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 16:23 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 16:58 +0000
Re: Overuse of 'auto' Richard Damon <Richard@Damon-Family.org> - 2022-12-21 12:02 -0500
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 17:18 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-21 10:24 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:10 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 10:35 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:05 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-21 11:13 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:21 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 16:19 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:00 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 10:32 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:11 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 13:05 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 15:31 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-19 16:55 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 18:04 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 10:28 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 19:20 -0800
Re: Overuse of 'auto' red floyd <no.spam.here@its.invalid> - 2022-12-19 22:13 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 22:20 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 22:23 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:12 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-19 22:45 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:16 +0000
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-20 10:22 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:39 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 21:09 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:16 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-29 13:25 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-31 15:00 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-31 16:20 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-31 14:47 -0800
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-31 17:47 -0800
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-31 07:58 -0800
Re: Overuse of 'auto' Jack Lemmon <invalid@invalid.net> - 2022-12-31 18:03 +0000
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-31 14:46 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 06:24 +0000
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2023-01-03 01:49 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 10:05 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-03 10:14 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-03 11:04 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-03 15:20 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 07:23 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-03 23:29 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-03 23:30 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 01:41 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 08:35 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-04 22:48 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-05 09:14 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-05 16:34 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-06 13:02 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-06 14:31 +0100
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2023-01-05 16:48 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-06 13:18 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2023-01-06 16:45 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-09 05:17 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2023-01-09 00:45 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-09 13:26 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-10 05:56 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2023-01-09 22:48 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-10 11:08 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2023-01-10 03:28 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-10 16:26 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2023-01-10 07:48 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-10 09:11 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-10 17:16 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-10 21:38 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-10 12:48 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-11 05:47 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-11 09:21 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-13 07:51 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-13 10:14 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-13 12:45 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-13 14:08 +0000
Re: Overuse of 'auto' Daniel <danielaparker@gmail.com> - 2023-01-13 06:18 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-14 07:24 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-16 11:17 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-24 07:17 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-24 09:35 +0100
Re: Overuse of 'auto' Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-24 03:09 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-13 16:08 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2023-01-11 13:20 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-23 23:23 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-23 23:26 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-04 09:23 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 11:03 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-04 11:31 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 13:09 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2023-01-04 15:58 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2023-01-03 10:49 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-03 15:57 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:32 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 13:52 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 16:20 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:12 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-20 22:31 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:41 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 11:25 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 11:14 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-21 13:42 +0100
Re: Overuse of 'auto' Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-12-21 20:31 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-21 14:56 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-22 12:20 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-22 20:43 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-23 10:31 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-23 19:42 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 19:30 +0100
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 09:35 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 12:28 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 16:30 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-14 16:50 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 17:16 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 20:01 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:16 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-19 09:40 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 12:10 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 14:47 +0100
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-19 16:52 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 18:08 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-19 10:36 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:23 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-20 01:01 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:44 +0000
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-20 10:30 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 10:21 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:46 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 12:48 -0800
Re: Overuse of 'auto' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-28 13:38 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:19 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 05:58 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 22:05 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 10:18 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 10:49 +0000
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-20 11:19 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 11:53 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 14:44 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:42 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:43 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 13:54 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-15 07:11 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:39 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-19 05:27 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 15:55 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-20 03:28 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 12:09 +0000
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-20 14:45 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 20:58 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:23 +0000
Re: Overuse of 'auto' Öö Tiib <ootiib@hot.ee> - 2022-12-20 08:58 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 06:30 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-20 22:36 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-21 08:24 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 01:49 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2023-01-04 11:07 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 13:41 -0800
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-21 15:38 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-22 12:32 +0000
Re: Overuse of 'auto' scott@slp53.sl.home (Scott Lurndal) - 2022-12-22 16:20 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-22 17:04 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-13 06:43 -0800
Re: Overuse of 'auto' Udo Steinbach <trashcan@udoline.de> - 2022-12-14 18:43 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 20:06 +0100
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-14 22:14 +0200
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-14 22:26 +0200
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-15 10:26 +0100
Re: Overuse of 'auto' Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-15 12:40 +0200
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:54 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:18 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-12 09:38 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-12 16:32 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-13 08:13 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-13 17:16 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-13 11:10 -0800
Re: Overuse of 'auto' Muttley@dastardlyhq.com - 2022-12-14 09:33 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 14:16 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 08:58 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:20 +0100
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-14 11:54 +0000
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-14 09:40 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-14 22:15 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-15 10:34 +0100
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-09 13:05 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 07:04 +0000
Re: Overuse of 'auto' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 12:25 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-29 20:27 +0000
Re: Overuse of 'auto' Lynn McGuire <lynnmcguire5@gmail.com> - 2022-12-09 15:25 -0600
Re: Overuse of 'auto' Christian Gollwitzer <auriocus@gmx.de> - 2022-12-10 16:29 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-10 15:39 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 07:10 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-12 09:49 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-12 11:35 +0000
Re: Overuse of 'auto' Udo Steinbach <trashcan@udoline.de> - 2022-12-14 20:03 +0100
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 20:18 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 09:06 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:39 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-19 07:10 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 13:46 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-20 07:10 -0800
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-20 18:39 +0100
Re: Overuse of 'auto' "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-12-20 11:20 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 16:03 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-11 14:31 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 16:04 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 00:33 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 17:13 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 17:25 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 01:47 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 17:48 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 19:47 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 19:51 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 19:53 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 20:08 -0800
Re: Overuse of 'auto' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 11:38 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-13 13:09 -0800
Re: Overuse of 'auto' Christian Gollwitzer <auriocus@gmx.de> - 2022-12-15 22:29 +0100
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-15 18:29 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-14 08:38 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-14 14:23 +0100
Re: Overuse of 'auto' Michael S <already5chosen@yahoo.com> - 2022-12-14 08:36 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-14 23:25 -0800
Re: Overuse of 'auto' Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-12-17 21:01 +0000
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 09:15 +0000
Re: Overuse of 'auto' David Brown <david.brown@hesbynett.no> - 2022-12-19 15:48 +0100
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-19 16:06 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 19:11 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 21:09 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 06:35 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 23:11 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 23:12 -0800
Re: Overuse of 'auto' Juha Nieminen <nospam@thanks.invalid> - 2022-12-20 07:22 +0000
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 23:39 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 01:59 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:19 -0800
Re: Overuse of 'auto' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:22 -0800
Page 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
| From | Udo Steinbach <trashcan@udoline.de> |
|---|---|
| Date | 2022-12-14 17:50 +0100 |
| Message-ID | <tncut0$2r33q$1@dont-email.me> |
| In reply to | #87833 |
Am 2022-12-12 um 18:17 schrieb Scott Lurndal: > I'll take 'rval' over "returnValue" every time. And why not „CurrentTime“? I name variables after their content, not their function. One look on the return statement says the reader what it does return. What do you do if you have two return statements in which you return two different variables, name them rval1 and rval2? Or do you assign the second to rval before return? -- Fahrradverkehr in Deutschland: http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-14 17:13 +0000 |
| Message-ID | <ovnmL.6992$jiuc.441@fx44.iad> |
| In reply to | #87916 |
Udo Steinbach <trashcan@udoline.de> writes:
>Am 2022-12-12 um 18:17 schrieb Scott Lurndal:
>> I'll take 'rval' over "returnValue" every time.
>
>And why not „CurrentTime“? I name variables after their content, not their
>function. One look on the return statement says the reader what it does
>return.
>What do you do if you have two return statements in which you return two
>different variables, name them rval1 and rval2? Or do you assign the
>second to rval before return?
* @param iocb The IOCB describing the WRITE operation.
* @returns false if the operation succeeded, true for failure.
*/
bool
c_uniline_dlp::ocs_write(c_iocb *iocb)
{
uint8 cmd = iocb->get_op_var1();
bool rval = false;
switch (cmd) {
case IOD_OCSWRITE_WC:
lock();
rval = ocs_write_control(iocb);
unlock();
break;
case IOD_OCSWRITE_LOAD_FIRMWARE:
rval = load_firmware(iocb);
break;
case IOD_OCSWRITE_WC_RC:
case IOD_OCSWRITE_WC_RC_INH_TO:
lock();
u_write_failed = false;
u_write_complete = false;
rval = ocs_write_control(iocb);
if (rval) {
while (!u_write_complete) {
bool timeout = u_flip_read.timed_wait(&u_lock, u_write_timeout);
if (timeout && ((cmd & 1) == 0)) {
u_write_failed = true;
set_rd(iocb, IOT_WITH_EXCEPTIONS, RD1_OCS_TIMEOUT);
break;
}
}
if (!u_write_failed) {
stc_read_control(iocb, cmd&1);
}
}
unlock();
rval = false;
break;
default:
d_logger->log("%s OCS Unsupported write op '%1.1lx'\n",
u_dlp_name, iocb->get_op_var1());
set_rd(iocb, IOT_WITH_EXCEPTIONS, RD_DESCRIPTOR_ERROR);
break;
}
return rval;
}
Given multithreaded code and the required synchronization, it is wise
to limit the number of early 'return' statements in a function.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-14 20:01 +0200 |
| Message-ID | <tnd31c$2rd11$1@dont-email.me> |
| In reply to | #87919 |
14.12.2022 19:13 Scott Lurndal kirjutas:
> Udo Steinbach <trashcan@udoline.de> writes:
>> Am 2022-12-12 um 18:17 schrieb Scott Lurndal:
>>> I'll take 'rval' over "returnValue" every time.
>>
>> And why not „CurrentTime“? I name variables after their content, not their
>> function. One look on the return statement says the reader what it does
>> return.
>> What do you do if you have two return statements in which you return two
>> different variables, name them rval1 and rval2? Or do you assign the
>> second to rval before return?
>
> * @param iocb The IOCB describing the WRITE operation.
> * @returns false if the operation succeeded, true for failure.
> */
> bool
> c_uniline_dlp::ocs_write(c_iocb *iocb)
> {
> uint8 cmd = iocb->get_op_var1();
> bool rval = false;
>
> switch (cmd) {
> case IOD_OCSWRITE_WC:
> lock();
> rval = ocs_write_control(iocb);
> unlock();
> break;
> case IOD_OCSWRITE_LOAD_FIRMWARE:
> rval = load_firmware(iocb);
> break;
> case IOD_OCSWRITE_WC_RC:
> case IOD_OCSWRITE_WC_RC_INH_TO:
> lock();
> u_write_failed = false;
> u_write_complete = false;
> rval = ocs_write_control(iocb);
> if (rval) {
> while (!u_write_complete) {
> bool timeout = u_flip_read.timed_wait(&u_lock, u_write_timeout);
> if (timeout && ((cmd & 1) == 0)) {
> u_write_failed = true;
> set_rd(iocb, IOT_WITH_EXCEPTIONS, RD1_OCS_TIMEOUT);
> break;
> }
> }
> if (!u_write_failed) {
> stc_read_control(iocb, cmd&1);
> }
> }
> unlock();
> rval = false;
> break;
> default:
> d_logger->log("%s OCS Unsupported write op '%1.1lx'\n",
> u_dlp_name, iocb->get_op_var1());
> set_rd(iocb, IOT_WITH_EXCEPTIONS, RD_DESCRIPTOR_ERROR);
> break;
> }
>
> return rval;
> }
>
> Given multithreaded code and the required synchronization, it is wise
> to limit the number of early 'return' statements in a function.
Ant the reason to not use a C++-style RAII lock is ...? Nostalgy for C?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-14 18:12 +0000 |
| Message-ID | <qmomL.77097$gGD7.27940@fx11.iad> |
| In reply to | #87925 |
Paavo Helde <eesnimi@osa.pri.ee> writes:
>14.12.2022 19:13 Scott Lurndal kirjutas:
>> Udo Steinbach <trashcan@udoline.de> writes:
>>> Am 2022-12-12 um 18:17 schrieb Scott Lurndal:
>>>> I'll take 'rval' over "returnValue" every time.
>>>
>>> And why not „CurrentTime“? I name variables after their content, not their
>>> function. One look on the return statement says the reader what it does
>>> return.
>>> What do you do if you have two return statements in which you return two
>>> different variables, name them rval1 and rval2? Or do you assign the
>>> second to rval before return?
>>
>> * @param iocb The IOCB describing the WRITE operation.
>> * @returns false if the operation succeeded, true for failure.
>> */
>> bool
>> c_uniline_dlp::ocs_write(c_iocb *iocb)
>> {
>> uint8 cmd = iocb->get_op_var1();
>> bool rval = false;
>>
>> switch (cmd) {
>> case IOD_OCSWRITE_WC:
>> lock();
>> rval = ocs_write_control(iocb);
>> unlock();
>> break;
>> case IOD_OCSWRITE_LOAD_FIRMWARE:
>> rval = load_firmware(iocb);
>> break;
>> case IOD_OCSWRITE_WC_RC:
>> case IOD_OCSWRITE_WC_RC_INH_TO:
>> lock();
>> u_write_failed = false;
>> u_write_complete = false;
>> rval = ocs_write_control(iocb);
>> if (rval) {
>> while (!u_write_complete) {
>> bool timeout = u_flip_read.timed_wait(&u_lock, u_write_timeout);
>> if (timeout && ((cmd & 1) == 0)) {
>> u_write_failed = true;
>> set_rd(iocb, IOT_WITH_EXCEPTIONS, RD1_OCS_TIMEOUT);
>> break;
>> }
>> }
>> if (!u_write_failed) {
>> stc_read_control(iocb, cmd&1);
>> }
>> }
>> unlock();
>> rval = false;
>> break;
>> default:
>> d_logger->log("%s OCS Unsupported write op '%1.1lx'\n",
>> u_dlp_name, iocb->get_op_var1());
>> set_rd(iocb, IOT_WITH_EXCEPTIONS, RD_DESCRIPTOR_ERROR);
>> break;
>> }
>>
>> return rval;
>> }
>>
>> Given multithreaded code and the required synchronization, it is wise
>> to limit the number of early 'return' statements in a function.
>
>Ant the reason to not use a C++-style RAII lock is ...? Nostalgy for C?
>
1) the code was written quite some time ago, C++ 2.1 era.
2) I prefer to keep critical sections as small as possible,
particularly in CPU-bound multithreaded applications like this one.
3) I've found that using RAII prevents the programmer from actually thinking
and reasoning about the critical section; instead they just blindly lock
an entire function and all the functions called from it (which may acquire
locks of their own, and may even recurse).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-12 10:25 -0800 |
| Message-ID | <87sfhktr6s.fsf@nosuchdomain.example.com> |
| In reply to | #87831 |
Juha Nieminen <nospam@thanks.invalid> writes:
> David Brown <david.brown@hesbynett.no> wrote:
>>>> This is especially true given that
>>>> full types in C++ can regularly take more than a single line to write out.
>>>
>>> There we go again with the brevity argument.
>>
>> If you can't see the wood for the trees, the code is unhelpfully
>> long-winded.
>
> I don't think you understand.
>
> The driving principle in writing code should be "this makes it easier to
> understand", not "this makes it shorter".
I think he *does* understand, but he disagrees.
It's easy to assume that someone can only disagree with you because they
don't understand what you're saying.
[...]
>>> Keep your code smart, not stupid.
>>
>> KISS means "Keep it simple, stupid" - not "Keep it stupid".
>
> I suppose you choose to insult your readers then, rather than the second S
> referring to the code itself.
The acronym "KISS" definitely expands to "Keep it simple, stupid", and
has since 1960. Nobody here chose what it means. Don't take it
personally.
https://en.wikipedia.org/wiki/KISS_principle
> Either way, I'd rather code be readable and understandable than simple.
If those goals conflict, I agree. They very often do not conflict.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-13 08:32 +0000 |
| Message-ID | <tn9dbi$1cqg$1@gioia.aioe.org> |
| In reply to | #87835 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >> David Brown <david.brown@hesbynett.no> wrote: >>>>> This is especially true given that >>>>> full types in C++ can regularly take more than a single line to write out. >>>> >>>> There we go again with the brevity argument. >>> >>> If you can't see the wood for the trees, the code is unhelpfully >>> long-winded. >> >> I don't think you understand. >> >> The driving principle in writing code should be "this makes it easier to >> understand", not "this makes it shorter". > > I think he *does* understand, but he disagrees. > > It's easy to assume that someone can only disagree with you because they > don't understand what you're saying. I didn't actually meant that he didn't understand what I was saying. My choice of words was poor. I meant it more like "you are missing the point". >>>> Keep your code smart, not stupid. >>> >>> KISS means "Keep it simple, stupid" - not "Keep it stupid". >> >> I suppose you choose to insult your readers then, rather than the second S >> referring to the code itself. > > The acronym "KISS" definitely expands to "Keep it simple, stupid", and > has since 1960. Nobody here chose what it means. I know perfectly well what it expands to, and I still maintain that if you deliberately want to interpret it as the "stupid" referring to the person that the sentiment is directed to, it's insulting. I don't care if that's exactly what it originally meant. If it was originally insulting, then it's still insulting. I don't even understand what the person who came up with it was thinking. No wonder there are myriads of alternatives that replace the "stupid" with something less offensive. I kind of give the benefit of the doubt to the original author of the acronym and prefer to interpret it as it referring to keeping the thing "simple and stupid", rather than keeping the thing "simple" and calling the person "stupid". (If this is the interpretation, then "keeping the thing stupid" would mean something like "don't try to make it too clever for its own good". After all "stupid" and "simple" can be thought of as synonyms.) >> Either way, I'd rather code be readable and understandable than simple. > > If those goals conflict, I agree. They very often do not conflict. When "simple" is interpreted as "short" (eg. using just one word instead of three) then quite often they are in conflict, especially when speaking about code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-13 01:11 -0800 |
| Message-ID | <87fsdju0q2.fsf@nosuchdomain.example.com> |
| In reply to | #87856 |
Juha Nieminen <nospam@thanks.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Juha Nieminen <nospam@thanks.invalid> writes:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>> This is especially true given that
>>>>>> full types in C++ can regularly take more than a single line to write out.
>>>>>
>>>>> There we go again with the brevity argument.
>>>>
>>>> If you can't see the wood for the trees, the code is unhelpfully
>>>> long-winded.
>>>
>>> I don't think you understand.
>>>
>>> The driving principle in writing code should be "this makes it easier to
>>> understand", not "this makes it shorter".
>>
>> I think he *does* understand, but he disagrees.
>>
>> It's easy to assume that someone can only disagree with you because they
>> don't understand what you're saying.
>
> I didn't actually meant that he didn't understand what I was saying.
> My choice of words was poor. I meant it more like "you are missing the
> point".
I doubt that he his, but I'll refrain from further attempts to speak for him.
>>>>> Keep your code smart, not stupid.
>>>>
>>>> KISS means "Keep it simple, stupid" - not "Keep it stupid".
>>>
>>> I suppose you choose to insult your readers then, rather than the second S
>>> referring to the code itself.
>>
>> The acronym "KISS" definitely expands to "Keep it simple, stupid", and
>> has since 1960. Nobody here chose what it means.
>
> I know perfectly well what it expands to, and I still maintain that if you
> deliberately want to interpret it as the "stupid" referring to the person
> that the sentiment is directed to, it's insulting. I don't care if that's
> exactly what it originally meant. If it was originally insulting, then it's
> still insulting. I don't even understand what the person who came up with
> it was thinking. No wonder there are myriads of alternatives that replace
> the "stupid" with something less offensive.
That's a valid opinion, but plenty of people use the term, knowing
exactly what it means, without meaning to be insulting. It's
humor, which can be a very individual thing. I understand that you find
it offensive. Please understand that others find it more humorous than
offensive, even understanding what it means.
If someone directly calls me stupid, I'll be insulted. But as part of a
well known saying that's been around for decades, it's different in ways
I'm not sure I can explain. And I'm at least as likely to apply it to
myself as to others.
See also RTFM.
> I kind of give the benefit of the doubt to the original author of the
> acronym and prefer to interpret it as it referring to keeping the thing
> "simple and stupid", rather than keeping the thing "simple" and calling
> the person "stupid". (If this is the interpretation, then "keeping the
> thing stupid" would mean something like "don't try to make it too clever
> for its own good". After all "stupid" and "simple" can be thought of
> as synonyms.)
It's not at all plausible that Kelly Johnson, cited as the originator of
the term, meant "simple and stupid". It's 100% clear that the word
"simple" refers to the thing and "stupid" refers to the person being
spoken to (implying that they're stupid for not designing the thing to
be simple). Again, I understand if you find that insulting, but it's a
form of humor that a lot of us find amusing and inoffensive.
>>> Either way, I'd rather code be readable and understandable than simple.
>>
>> If those goals conflict, I agree. They very often do not conflict.
>
> When "simple" is interpreted as "short" (eg. using just one word
> instead of three) then quite often they are in conflict, especially
> when speaking about code.
I don't think anyone is arguing that brevity is the only thing that
contributes to simplicity.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-13 14:31 +0100 |
| Message-ID | <tn9ur1$2h56l$1@dont-email.me> |
| In reply to | #87859 |
On 13/12/2022 10:11, Keith Thompson wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> Juha Nieminen <nospam@thanks.invalid> writes: >>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>>> This is especially true given that >>>>>>> full types in C++ can regularly take more than a single line to write out. >>>>>> >>>>>> There we go again with the brevity argument. >>>>> >>>>> If you can't see the wood for the trees, the code is unhelpfully >>>>> long-winded. >>>> >>>> I don't think you understand. >>>> >>>> The driving principle in writing code should be "this makes it easier to >>>> understand", not "this makes it shorter". >>> >>> I think he *does* understand, but he disagrees. >>> >>> It's easy to assume that someone can only disagree with you because they >>> don't understand what you're saying. >> >> I didn't actually meant that he didn't understand what I was saying. >> My choice of words was poor. I meant it more like "you are missing the >> point". > > I doubt that he his, but I'll refrain from further attempts to speak for him. You are doing fine so far :-) Yes, I understand Juha's point, but I disagree with it. At least, I disagree with the level or strength of it. Clear code is vitally important in all but throw-away code. (Remember Heathfield's rule? It's easier to make clear code correct than to make correct code clear. It's easier to make correct code fast than to make fast code correct. So always code for clarity.) And awkward or exaggerated abbreviations make code unclear. They may seem fine at the time to the person writing the code, but it's a different matter a decade later for someone else maintaining it. So I think there is a scale here of some kind, from short, concise or abbreviated at one end and long-winded, explicit and expanded at the other end. I think (unjustifiably speaking for everyone here!) we all agree that being too close to the short end is a bad idea. The disagreement is towards the other end - I say that's bad too, while Juha, AFAICS, disagrees. > >>>>>> Keep your code smart, not stupid. >>>>> >>>>> KISS means "Keep it simple, stupid" - not "Keep it stupid". >>>> >>>> I suppose you choose to insult your readers then, rather than the second S >>>> referring to the code itself. >>> >>> The acronym "KISS" definitely expands to "Keep it simple, stupid", and >>> has since 1960. Nobody here chose what it means. >> >> I know perfectly well what it expands to, and I still maintain that if you >> deliberately want to interpret it as the "stupid" referring to the person >> that the sentiment is directed to, it's insulting. I don't care if that's >> exactly what it originally meant. If it was originally insulting, then it's >> still insulting. I don't even understand what the person who came up with >> it was thinking. No wonder there are myriads of alternatives that replace >> the "stupid" with something less offensive. > > That's a valid opinion, but plenty of people use the term, knowing > exactly what it means, without meaning to be insulting. It's > humor, which can be a very individual thing. I understand that you find > it offensive. Please understand that others find it more humorous than > offensive, even understanding what it means. > > If someone directly calls me stupid, I'll be insulted. But as part of a > well known saying that's been around for decades, it's different in ways > I'm not sure I can explain. And I'm at least as likely to apply it to > myself as to others. > > See also RTFM. If someone is directly called "stupid", it is insulting. However, it's a different matter if someone says "you're being stupid", or "that code you wrote is stupid", or "you said something stupid". I do not consider myself a stupid person - but like most people, I sometimes do stupid things or say something stupid. If someone gives me a piece of code to review and I return it with "KISS" scrawled across it in big red pen, I am /not/ calling the developer stupid - nor insulting them. I am telling them that I think the code has got out of hand and ended up being too complex - and that they could do a better job if they simplified it. (I haven't done this with a code review, but I did do it once with an electronics design review. The designer was not insulted, and agreed with my point.)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-13 13:42 +0000 |
| Message-ID | <tn9vfc$2ij$1@gioia.aioe.org> |
| In reply to | #87866 |
David Brown <david.brown@hesbynett.no> wrote: > So I think there is a scale here of some kind, from short, concise or > abbreviated at one end and long-winded, explicit and expanded at the > other end. I think (unjustifiably speaking for everyone here!) we all > agree that being too close to the short end is a bad idea. The > disagreement is towards the other end - I say that's bad too, while > Juha, AFAICS, disagrees. I don't really understand why this seems to be so hard to explain. I don't want names that are long. I want names that are clear, unambiguous and easy to understand, which convey as well as possible what the name is representing. Overtly short abbreviated names do not convey that, and code that's too compressed and contains too much information packed in too little space does not achieve that. The goal is not to make names or code longer. That's just a side-effect of making code clearer and easier to understand. And yes, it is perfectly possible to go too far in the other direction. But that has nothing to do with what I'm saying. I want clarity, not length. Clarity sometimes requires increasing length a bit, but that in itself is irrelevant, it's just a side effect. Thus I find it ridiculous when people post "counter-examples" that are names that are overly long and contain a lot of rendunancy. I'm not looking for long names. I'm looking for clear names. There's a difference. How hard is this to understand, really?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-13 09:42 +0100 |
| Message-ID | <tn9dt7$2fnt5$1@dont-email.me> |
| In reply to | #87831 |
On 12/12/2022 16:59, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>>>> This is especially true given that
>>>> full types in C++ can regularly take more than a single line to write out.
>>>
>>> There we go again with the brevity argument.
>>
>> If you can't see the wood for the trees, the code is unhelpfully
>> long-winded.
>
> I don't think you understand.
>
> The driving principle in writing code should be "this makes it easier to
> understand", not "this makes it shorter".
>
Of course I understand, and agree with that principle. The sticking
point seems to be that you apparently have difficulty understanding that
short code can be easy to understand - easier than long versions.
Sometimes it is simply the fact that the code is shorter that makes it
easier to understand - people generally write "long" instead of "signed
long int" precisely because it is shorter and requires less cognitive
effort to understand.
"auto", used appropriately, can do the same thing.
> It's not about making the names longer for the sake of making them longer.
> It's about making them easier to understand. If that means writing longer
> names, then so be it. There's zero reason to avoid longer names, if that
> makes the code clearer for the reader who is reading the code for the
> first time. (Conversely, if a name is so long that it makes it harder to
> understand, then express it more concisely and clearly.)
>
> The problem is that the majority of programmers do not choose names based
> on how easy it makes the code to understand for third-parties. They choose
> the names based on personal preference, which in the vast, vast majority
> of cases means overtly short names. Most programmers prefer writing "ret"
> instead of "returnValue", "err" instead of "errorCode", "genRandVal"
> instead of "generateRandomValue". They do not think if that makes the
> code harder for someone else to read. (And in the majority of cases if
> you point this out, they will ferociously defend their practice, against
> all logic.)
Of course they write "ret" instead of "returnValue" - it makes the code
easier to understand!
Choosing and using good names is an art. There are guidelines, but no
fixed rules. Like many stylistic aspects of programming, it can depend
significantly on the size of the project, the size of the development
group, the lifetime of the code, the type of code, and many other factors.
One common rule, however, is that the bigger the scope of an identifier,
the longer and more explicit it must be. Inside a short loop, you use
an index variable "i" because it is short and /clear/. Calling it
"loop_index_counter" makes the code harder to read and understand -
longer and more explicit is directly counter-productive. A function
that could be called from anywhere in a million-line program, on the
other hand, needs a very good and clear name - though that is almost
certainly best done via appropriate uses of namespaces (or other
structured naming) rather than a long identifier. (C++ is not C.)
Compare:
int calculate_average_of_vector_of_ints(std::vector<int>
vector_of_ints_to_average)
{
int sum_so_far = 0;
for (this_int : vector_of_ints_to_average) {
sum_so_far += this_int;
}
int the_size_of_the_vector_of_ints_to_average =
vector_of_ints_to_average.size();
int return_value = sum_so_far /
the_size_of_the_vector_of_ints_to_average;
return return_value;
}
with :
int average(std::vector<int> xs) {
{
int sum = 0;
for (x : xs) {
sum += x;
}
return sum / xs.size();
}
Are you seriously suggesting that the first version is "clearer" or
easier to understand, because it has long, explicit names?
If I see someone use a variable called "returnValue" in something
presented for code review, I'd reject it. It's a name that means
nothing (what information does it give you in "return returnValue;" ?)
The only conceivable reason to have it is that the function is so long
the it is unclear what it is returning - and /that/ is the problem to fix.
The same goes for "errorCode". If it is not clear from the code that
"err" is an error code, /that/ is the problem - not the name of the
variable.
If we are talking about functions accessible from far off in the code,
then longer names are needed. But not local names.
>
> If 'std::map<std::string, std::string>' makes the code easier to understand
> than 'auto', then write the former. There's no need to save disk space.
> Shorter is not always better.
I fully agree - no one has argued any differently.
What people (generalising wildly from myself) are reacting against is
your idea that shorter /cannot/ be better, or that longer is /always/
better.
When used correctly, shorter most certainly can be better precisely
because it is clearer and easier to understand - and it is clearer and
easier to understand precisely because it is better.
That only applies when it is clear what the identifier means, of course.
And that will vary enormously according to the rest of the code.
>
>>> Length does not matter. Clarity does.
>>
>> If you think clarity increases with length, you haven't read enough
>> code. Tens of thousands of lines is not a lot.
>
> I have read enough code to know that brevity does not increase clarity,
> but the opposite.
>
>> Let's take a different case. If I want an integer to store numbers in
>> the range of 15 decimal digits, I'll write :
>>
>> int64_t x;
>>
>> I won't write :
>>
>> signed long long int x;
>>
>> even though the later is more portable, more explicit, and avoids an
>> unnecessary non-portable requirement of the implementation having a type
>> of exactly 64 bits.
>
> You are now trying to argue from redundancy. 'signed' and 'int' are
> redundant there. They don't add information. There's no need to say the
> same thing multiple times.
You are being inconsistent. Writing "signed" makes it clear and
explicit that we are dealing with signed types - no one has to read
"int" or "int64_t" and remember that by default integers are signed in
C++. Or are you happy that /sometimes/ it's okay to write short code
whose meaning is clear to everyone reading it, and you don't have to
write out /everything/ in the longest, most explicit manner?
I think it turns out that you too understand that "a happy medium" is
the ideal - not too long, not too short, not too explicit, not too
implicit. You might have a personal preference towards slightly longer
than the preferences of the "average" programmer, but that's detail
rather than principle.
>
> Also, those two lines are not equivalent. It's not *merely* about naming
> conventions in this example. There's a functional difference.
>
There is - and I know the difference, and stated it. But I actively
choose the version that is marginally subpar in the technicalities of
what the code means, precisely because the "int64_t" version is clearer
and easier to understand, primarily because it is shorter.
>>> Keep your code smart, not stupid.
>>
>> KISS means "Keep it simple, stupid" - not "Keep it stupid".
>
> I suppose you choose to insult your readers then, rather than the second S
> referring to the code itself.
>
"KISS" is a well-known acronym and guiding principle throughout
engineering (not just programming). The "stupid" is not an insult as
such, and is targeted at the developer not the reader - it means it is a
stupid idea to make things more complicated than necessary.
If you prefer Einstein's version, "make things as simple as possible,
but no simpler".
> Either way, I'd rather code be readable and understandable than simple.
I'd rather it be /both/ - because they are strongly correlated. Simple
code is easier to read and understand.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-13 10:20 +0000 |
| Message-ID | <tn9jke$8op$1@gioia.aioe.org> |
| In reply to | #87858 |
David Brown <david.brown@hesbynett.no> wrote: > Of course I understand, and agree with that principle. The sticking > point seems to be that you apparently have difficulty understanding that > short code can be easy to understand - easier than long versions. Believe me, by this point in my life I have read enough other people's code to know for a fact that overtly short naming schemes make code harder to understand, not easier. You can claim the opposite until the cows come home, but you cannot erase my personal experience of *actually* having read *tons and tons* of code written by other people, and seeing the difference it makes when things are clearly named vs. when cryptic abbreviations and acronyms are used, or when too few words are used to describe the variable, function or type, or when eg. types are being hidden behind 'auto' keywords for no good reason. (Also, when function overloading is overused for no good reason.) > Sometimes it is simply the fact that the code is shorter that makes it > easier to understand - people generally write "long" instead of "signed > long int" precisely because it is shorter and requires less cognitive > effort to understand. There's absolutely nothing in "signed long int" that makes it harder to understand than "long". It just has a lot of redundancy that doesn't add any relevant information. But compare that to, for example let's say, a function named "generate()". Generate what, exactly? That function name would benefit a great deal from additional words that describe what it's generating (and this information would not be redundant). Or consider a function named "convert()". Convert what, exactly? And into what? This, too, would greatly benefit from having more words telling the reader what it's doing. This is different from "signed long" vs "long", where the additional word doesn't add any new clarifying information and is redundant. But by all means, if you want to specify the 'signed' for extra clarity, go right ahead. It doesn't make it harder to understand. > "auto", used appropriately, can do the same thing. I can't think of many situations where 'auto' actually increases how easy the code is to understand. There might be situations where it doesn't decrease understandability, but not many situations where it actually increases it. > Of course they write "ret" instead of "returnValue" - it makes the code > easier to understand! It absolutely doesn't. It only makes code more compressed and removes useful information. At the very most you could perhaps claim that it doesn't make the code harder to understand. It absoutely does not make the code *easier* to understand. > One common rule, however, is that the bigger the scope of an identifier, > the longer and more explicit it must be. Inside a short loop, you use > an index variable "i" because it is short and /clear/. Calling it > "loop_index_counter" makes the code harder to read and understand - > longer and more explicit is directly counter-productive. It being longer doesn't make it harder to understand. In this particular example you are just, once again, adding *redundant* information to it. "index" is better than both "i" (because "index" is an actual English word that expresses what the variable is) and "loop_index_counter" (because it contains useless redundant information). A better name than "index" would be to express what it's indexing. For example "coordinate_index", or "word_index", or "column_index", or whatever it's indexing is better than just "index" because it's actually telling you what it's used for. For the millionth time: It's not about making the names *longer*. It's about making the *clearer*. There's a difference. Do you understand what I'm trying to say?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-13 11:10 +0000 |
| Message-ID | <tn9mjl$1oie$1@gioia.aioe.org> |
| In reply to | #87860 |
Juha Nieminen <nospam@thanks.invalid> wrote: > Believe me, by this point in my life I have read enough other people's > code to know for a fact that overtly short naming schemes make code harder > to understand, not easier. Not that probably anybody is interested, but anyway, after all that I have come up with a few principles when it comes to naming in order to make code easier for a third-party (who has never seen the code before) to read: - Always use full English words instead of contractions and acronyms. "return_value" is better than "ret". "error_code" is better than "err". "generateRandomValue" is better than "genRandVal". "column_index" is better than "i". (An exception is if the contraction or acronym is universally used and understood, like "GPS", "HDMI", "cos", "tan", etc.) - Use as many words as needed to make it clear what the variable, function or type is doing (but in general avoid redundancy, as that doesn't really add any useful information to the name). "error_code" is better than "error" or "code". "convert_to_utf16_from_utf8" is better than "convert". (Note: It's not about making the name longer. It's about making it clearer and more unambiguous, and easier to understand what it's doing.) - Don't use function overloading unless there's an actual good reason to use it (eg. because the function will be used in templated code). Avoid overloading just for the sake of overloading. Always name the functions in a disambiguating descriptive manner and prefer unique names, if possible. (Even when overloading is needed, prefer still implementing the functions with unique names, and make the overloads call those. In code that doesn't need the overloading call the uniquely named versions of the functions.) - Don't overuse 'auto'. Use it only when there's a good technical reason to use it. Don't use it to merely save typing, or as some kind of equivalent to a 'var' keyword in other languages. If there's a type that's extremely long when typed out in its entirety, you could create a 'using' alias that's shorter but still as clear and unambiguous as possible (that still makes it very clear what it is). - Almost always use namespace prefixes when using names inside a namespace, even in code that's inside the same namespace. (This is because when the namespace appears in the name, it makes it very clear that the name is from that namespace and not a function-local name, a class member, or a global name somewhere else.)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-13 15:58 +0000 |
| Message-ID | <tna7es$cmi$1@gioia.aioe.org> |
| In reply to | #87862 |
On Tue, 13 Dec 2022 11:10:47 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Juha Nieminen <nospam@thanks.invalid> wrote: >> Believe me, by this point in my life I have read enough other people's >> code to know for a fact that overtly short naming schemes make code harder >> to understand, not easier. > >Not that probably anybody is interested, but anyway, after all that I have >come up with a few principles when it comes to naming in order to make >code easier for a third-party (who has never seen the code before) to read: > >- Always use full English words instead of contractions and acronyms. >"return_value" is better than "ret". "error_code" is better than "err". >"generateRandomValue" is better than "genRandVal". "column_index" is >better than "i". Not if you end up with a wall of text like a lot of Java code. >(An exception is if the contraction or acronym is universally used and >understood, like "GPS", "HDMI", "cos", "tan", etc.) 'i' is VERY common as an index value in for(). >- Almost always use namespace prefixes when using names inside a >namespace, even in code that's inside the same namespace. (This is >because when the namespace appears in the name, it makes it very >clear that the name is from that namespace and not a function-local >name, a class member, or a global name somewhere else.) In that case whats the point of having a namespace at all? You can achieve exactly the same result C style with function naming. Eg: instead of mylib::func() you can just call it mylib_func().
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-14 06:23 +0000 |
| Message-ID | <tnbq47$hvq$1@gioia.aioe.org> |
| In reply to | #87872 |
Muttley@dastardlyhq.com wrote: >>- Always use full English words instead of contractions and acronyms. >>"return_value" is better than "ret". "error_code" is better than "err". >>"generateRandomValue" is better than "genRandVal". "column_index" is >>better than "i". > > Not if you end up with a wall of text like a lot of Java code. And there we go again with the length argument. Length. Does. Not. Matter. What matters is readability. >>(An exception is if the contraction or acronym is universally used and >>understood, like "GPS", "HDMI", "cos", "tan", etc.) > > 'i' is VERY common as an index value in for(). But since 'i' does not refer to anything specific, it's better and more readable if you express what you are indexing with it. This is especially true the more loops there are (they don't even have to be nested). I honestly cannot understand why you are even opposing that. >>- Almost always use namespace prefixes when using names inside a >>namespace, even in code that's inside the same namespace. (This is >>because when the namespace appears in the name, it makes it very >>clear that the name is from that namespace and not a function-local >>name, a class member, or a global name somewhere else.) > > In that case whats the point of having a namespace at all? You can achieve > exactly the same result C style with function naming. Eg: instead of > mylib::func() you can just call it mylib_func(). If you want to do that, go right ahead.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-14 07:36 +0000 |
| Message-ID | <tnbud2$1u7c$1@gioia.aioe.org> |
| In reply to | #87884 |
Juha Nieminen <nospam@thanks.invalid> wrote: >>>- Almost always use namespace prefixes when using names inside a >>>namespace, even in code that's inside the same namespace. (This is >>>because when the namespace appears in the name, it makes it very >>>clear that the name is from that namespace and not a function-local >>>name, a class member, or a global name somewhere else.) >> >> In that case whats the point of having a namespace at all? You can achieve >> exactly the same result C style with function naming. Eg: instead of >> mylib::func() you can just call it mylib_func(). > > If you want to do that, go right ahead. In fact, I have noticed a rather interesting psychological phenomenon related to this. Many C++ programmers will fight tooth and nail to defend their practice of not writing namespace prefixes and the use of 'using' to allow them to do that... and the exact same people never, ever, ever complaining about having to write prefixes in names declared in many C libraries. They hate the guts of namespace prefixes, but they have zero problems if the prefix is actually in the names themselves, separated with an underscore instead of ::. Why? Your guess is as good as mine. I could present some shaky psychological hypotheses, but ultimately I have no idea. So, in this sense, it's actually *better* to attach the namespace to the names themselves (with an underscore) because that will stop people from going their way to avoid writing those prefixes, and their code will automatically become more readable, and they will stop complaining about the namespace prefixes. Take advantage of this curious psychological phenomenon.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-14 09:43 +0000 |
| Message-ID | <tnc5st$12sd$1@gioia.aioe.org> |
| In reply to | #87886 |
On Wed, 14 Dec 2022 07:36:04 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Juha Nieminen <nospam@thanks.invalid> wrote: >>>>- Almost always use namespace prefixes when using names inside a >>>>namespace, even in code that's inside the same namespace. (This is >>>>because when the namespace appears in the name, it makes it very >>>>clear that the name is from that namespace and not a function-local >>>>name, a class member, or a global name somewhere else.) >>> >>> In that case whats the point of having a namespace at all? You can achieve >>> exactly the same result C style with function naming. Eg: instead of >>> mylib::func() you can just call it mylib_func(). >> >> If you want to do that, go right ahead. > >In fact, I have noticed a rather interesting psychological phenomenon >related to this. > >Many C++ programmers will fight tooth and nail to defend their practice >of not writing namespace prefixes and the use of 'using' to allow them >to do that... and the exact same people never, ever, ever complaining >about having to write prefixes in names declared in many C libraries. Err, because there's no choice with C? >They hate the guts of namespace prefixes, but they have zero problems >if the prefix is actually in the names themselves, separated with an >underscore instead of ::. > >Why? Your guess is as good as mine. I could present some shaky >psychological hypotheses, but ultimately I have no idea. > >So, in this sense, it's actually *better* to attach the namespace to >the names themselves (with an underscore) because that will stop people >from going their way to avoid writing those prefixes, and their code >will automatically become more readable, and they will stop complaining >about the namespace prefixes. Take advantage of this curious psychological >phenomenon. You need to look in the mirror. *You* are the one who uses the namespace name *inside* itself. How is mynamespace::func() any different from writing mynamespace_func()? Most sensible C++ devs would just write func() inside that namespace which is the whole point of namespaces. Why did you think they were invented in the first place? Bjorn could have just gone with long function prefixes.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-14 12:19 +0000 |
| Message-ID | <tncf0n$1b25$1@gioia.aioe.org> |
| In reply to | #87894 |
Muttley@dastardlyhq.com wrote: > You need to look in the mirror. *You* are the one who uses the namespace name > *inside* itself. How is mynamespace::func() any different from writing > mynamespace_func()? In the latter the prefix is mandatory, in the former it's not. With the prefix it becomes a lot clearer where that func() is, and thus the code is much easier to understand. > Most sensible C++ devs would just write func() inside that namespace which > is the whole point of namespaces. Why did you think they were invented in > the first place? Bjorn could have just gone with long function prefixes. Bjarne. And he isn't a Perfect God who is always right. Namespaces can have other uses, such as bringing the names of one namespace into another (which, in a way, is a bit like "inheriting" the other namespace).
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-14 16:24 +0000 |
| Message-ID | <tnctbh$6fp$1@gioia.aioe.org> |
| In reply to | #87900 |
On Wed, 14 Dec 2022 12:19:37 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Muttley@dastardlyhq.com wrote: >> You need to look in the mirror. *You* are the one who uses the namespace >name >> *inside* itself. How is mynamespace::func() any different from writing >> mynamespace_func()? > >In the latter the prefix is mandatory, in the former it's not. No shit. Well done on completely missing my point. >With the prefix it becomes a lot clearer where that func() is, and thus >the code is much easier to understand. So why not just use prefixes instead of namespaces? >> Most sensible C++ devs would just write func() inside that namespace which >> is the whole point of namespaces. Why did you think they were invented in >> the first place? Bjorn could have just gone with long function prefixes. > >Bjarne. And he isn't a Perfect God who is always right. > >Namespaces can have other uses, such as bringing the names of one namespace >into another (which, in a way, is a bit like "inheriting" the other >namespace). But you'd write the fully expressed name anyway, right?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 07:35 +0000 |
| Message-ID | <tnp47s$bna$2@gioia.aioe.org> |
| In reply to | #87911 |
Muttley@dastardlyhq.com wrote: > On Wed, 14 Dec 2022 12:19:37 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >>Muttley@dastardlyhq.com wrote: >>> You need to look in the mirror. *You* are the one who uses the namespace >>name >>> *inside* itself. How is mynamespace::func() any different from writing >>> mynamespace_func()? >> >>In the latter the prefix is mandatory, in the former it's not. > > No shit. Well done on completely missing my point. > >>With the prefix it becomes a lot clearer where that func() is, and thus >>the code is much easier to understand. > > So why not just use prefixes instead of namespaces? If you want to use prefixes instead of namespaces, go right ahead. You'll be inducing the users of your library to write better clearer code, so there's a positive.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-14 14:11 +0100 |
| Message-ID | <tnci2r$2q2at$1@dont-email.me> |
| In reply to | #87886 |
On 14/12/2022 08:36, Juha Nieminen wrote: > Juha Nieminen <nospam@thanks.invalid> wrote: >>>> - Almost always use namespace prefixes when using names inside a >>>> namespace, even in code that's inside the same namespace. (This is >>>> because when the namespace appears in the name, it makes it very >>>> clear that the name is from that namespace and not a function-local >>>> name, a class member, or a global name somewhere else.) >>> >>> In that case whats the point of having a namespace at all? You can achieve >>> exactly the same result C style with function naming. Eg: instead of >>> mylib::func() you can just call it mylib_func(). >> >> If you want to do that, go right ahead. > > In fact, I have noticed a rather interesting psychological phenomenon > related to this. > > Many C++ programmers will fight tooth and nail to defend their practice > of not writing namespace prefixes and the use of 'using' to allow them > to do that... and the exact same people never, ever, ever complaining > about having to write prefixes in names declared in many C libraries. Really? I wonder if you have very odd colleagues, or if you interpret things differently from myself (and apparently some others in this thread). I use "using" locally in functions when it makes code simpler and clearer, because it makes names shorter and has less clutter. It also makes it clearer that I am "using" a particular imported namespace. If I have a namespace called "display", and I am writing a function that uses the display, it is a /good/ thing to write "using namespace display;" in that function. It is a /good/ thing to write "clear();" or "get_dimensions()" rather than "display::clear();" and "display::get_dimensions()". Obviously if there is ambiguity, you need to use namespace prefixes. In C, people /do/ grumble about long and awkward names with no scoping. They minimise the problem by using short abbreviations for their prefixes, and they don't complain too much because it is pointless to complain too much since there is no alternative. > > They hate the guts of namespace prefixes, but they have zero problems > if the prefix is actually in the names themselves, separated with an > underscore instead of ::. > As you have been doing throughout this thread, you are wildly exaggerating. People don't like having to write long prefixes when it is obvious from the context of the code which library or set of identifiers you are using. They don't like it in C, and they don't like it in C++. The difference is that in C you are stuck with using it, while in C++ you have multiple options for structured and scoped naming - and sometimes you have the option of reducing the verbosity by a "using" clause. > Why? Your guess is as good as mine. I could present some shaky > psychological hypotheses, but ultimately I have no idea. > > So, in this sense, it's actually *better* to attach the namespace to > the names themselves (with an underscore) because that will stop people > from going their way to avoid writing those prefixes, and their code > will automatically become more readable, and they will stop complaining > about the namespace prefixes. Take advantage of this curious psychological > phenomenon. I believe this "curious psychological phenomenon" is primarily in your own mind, not in the minds of other programmers.
[toc] | [prev] | [next] | [standalone]
Page 3 of 17 — ← Prev page 1 2 [3] 4 5 … 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web