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 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-14 20:06 +0100 |
| Message-ID | <tnd6rh$2rmfq$2@dont-email.me> |
| In reply to | #87924 |
On 14/12/2022 18:43, Udo Steinbach wrote:
> Am 2022-12-13 um 09:42 schrieb David Brown:
>> calculate_average_of_vector_of_ints() {
>> int the_size_of_the_vector_of_ints_to_average
>
> I love practical examples used to support the opposite practical point of view.
>
>> Are you seriously suggesting that the first version is "clearer"
>
> Cheap straw man.
> int CalcAverage(std::vector<int> Throughput) {
> { int Sum= 0;
> for (int Current : Throughput)
> Sum += Current;
> return Sum / Throughput.size();
> }
That's shorter names, that are easier to read. But I don't think they
are very good choices of names. It's a very general function, and yet
the way you have written it suggests it is only for calculating average
throughput. If that is the case, then the function name is bad - if it
is not the case, then the parameter name is bad.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-14 22:14 +0200 |
| Message-ID | <tndaqr$2rvfh$1@dont-email.me> |
| In reply to | #87858 |
13.12.2022 10:42 David Brown kirjutas:
> with :
>
> int average(std::vector<int> xs) {
> {
> int sum = 0;
> for (x : xs) {
> sum += x;
> }
> return sum / xs.size();
> }
I like the shorter version more. However, both versions have serious
deficiencies, not the point under discussion here, but I would still
point them out as there are so many of them, for 8 lines:
- parameter should be passed by const reference, not by value
- an int collector might easily overflow and cause UB
- type name or auto missing for x
- division by zero if xs is empty
- result value is truncated, not rounded, seems wrong for 'average'
- result value is potentially needlessly quantized to an integer value
And yes, all these deficiencies can be spotted better in the shorter
version, as there is less noise.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-14 22:26 +0200 |
| Message-ID | <tndbhj$2rvfh$2@dont-email.me> |
| In reply to | #87934 |
14.12.2022 22:14 Paavo Helde kirjutas:
> 13.12.2022 10:42 David Brown kirjutas:
>
>> with :
>>
>> int average(std::vector<int> xs) {
>> {
>> int sum = 0;
>> for (x : xs) {
>> sum += x;
>> }
>> return sum / xs.size();
>> }
>
> I like the shorter version more. However, both versions have serious
> deficiencies, not the point under discussion here, but I would still
> point them out as there are so many of them, for 8 lines:
>
> - parameter should be passed by const reference, not by value
> - an int collector might easily overflow and cause UB
> - type name or auto missing for x
> - division by zero if xs is empty
> - result value is truncated, not rounded, seems wrong for 'average'
> - result value is potentially needlessly quantized to an integer value
Oops, missed one:
- if sum comes out negative, dividing by size_t will produce unsigned
which will yield a wildly wrong result.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-15 10:26 +0100 |
| Message-ID | <tnep7a$32bv4$1@dont-email.me> |
| In reply to | #87934 |
On 14/12/2022 21:14, Paavo Helde wrote:
> 13.12.2022 10:42 David Brown kirjutas:
>
>> with :
>>
>> int average(std::vector<int> xs) {
>> {
>> int sum = 0;
>> for (x : xs) {
>> sum += x;
>> }
>> return sum / xs.size();
>> }
>
> I like the shorter version more. However, both versions have serious
> deficiencies, not the point under discussion here, but I would still
> point them out as there are so many of them, for 8 lines:
>
> - parameter should be passed by const reference, not by value
> - an int collector might easily overflow and cause UB
> - type name or auto missing for x
Silly me - that should have been "auto x", obviously!
> - division by zero if xs is empty
> - result value is truncated, not rounded, seems wrong for 'average'
> - result value is potentially needlessly quantized to an integer value
>
> And yes, all these deficiencies can be spotted better in the shorter
> version, as there is less noise.
Agreed on all points. And it's worth remembering that apparently simple
concepts can have complications.
(You could also have noted that std::accumulate or std::reduce could
have been an alternative to having a loop at all.)
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-15 12:40 +0200 |
| Message-ID | <tneti7$32i59$2@dont-email.me> |
| In reply to | #87945 |
15.12.2022 11:26 David Brown kirjutas:
> On 14/12/2022 21:14, Paavo Helde wrote:
>> 13.12.2022 10:42 David Brown kirjutas:
>>
>>> with :
>>>
>>> int average(std::vector<int> xs) {
>>> {
>>> int sum = 0;
>>> for (x : xs) {
>>> sum += x;
>>> }
>>> return sum / xs.size();
>>> }
>> - type name or auto missing for x
>
> Silly me - that should have been "auto x", obviously!
auto works fine here technically, even if it is one more character to
type than int. With auto it would also be less code to change if the
vector element type gets refactored to something else, like int64 or
templated T, and less potential conversions to worry about (with int I
would need to check if it matches the type of xs). So it's not
immediately clear to me that auto would be wrong here, especially as
type of xs is visible just 3 lines above.
But I would not like to enter into quarrels about that, I'm perfectly
fine with 'int x' as well.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 08:54 +0000 |
| Message-ID | <tnp8rh$bne$1@gioia.aioe.org> |
| In reply to | #87858 |
David Brown <david.brown@hesbynett.no> wrote: > int calculate_average_of_vector_of_ints(std::vector<int> > vector_of_ints_to_average) As always, you use redundant information to artificially lengthen names. That's arguing in bad faith. > 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. For starters, I gave "returnValue" as a better alternative to "ret". That "ret" is not giving you any more information than "returnValue", but it's more cryptic for no good reason. If you were to reject the use of "returnValue" in favor of "ret" then... well, it's better I don't continue this sentence. > 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. There's zero reason to make the name more cryptic than it has to be. You are now just arguing for the sake of arguing, and it makes no sense. I honestly cannot understand why this is so controversial and deserving of such strong opposition. It feels like I have been suggesting to use profanity, swearwords and politically offensive terminology in variable and function names. > 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? There we go again with the length argument. How many times do I have to repeat this? IT'S NOT ABOUT LENGTH! It's about legibility and understandability. Sometimes increased legibility makes names longer, but that's just an irrelevant side effect. The length itself is not the primary goal. How hard is that to understand, honestly?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-19 15:18 +0100 |
| Message-ID | <tnprrd$c0l9$1@dont-email.me> |
| In reply to | #88029 |
On 19/12/2022 09:54, Juha Nieminen wrote: > David Brown <david.brown@hesbynett.no> wrote: >> int calculate_average_of_vector_of_ints(std::vector<int> >> vector_of_ints_to_average) > > As always, you use redundant information to artificially lengthen names. > > That's arguing in bad faith. I'm arguing that giving full explicit descriptions in identifiers makes them harder to understand, and code is clearer when they are omitted. Pointing out the absurdity of your "longer is always better" idea is not arguing in bad faith. If I write : std::unique_ptr<Image> image_pointer = std::make_unique<Image> (image_file); then that is repeating redundant information in comparison to : auto pI = std::make_unique<Image>(image_file); (copying Öö's examples). Are you going to claim that the first use of redundant information is always bad but the second use of it is always good? Or could it be - as everyone but you has been saying all along - that it is easier to understand code without /excess/ information and redundancy? > >> 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. > > For starters, I gave "returnValue" as a better alternative to "ret". > That "ret" is not giving you any more information than "returnValue", > but it's more cryptic for no good reason. I agree it gives no extra information. I disagree that it is cryptic, and I disagree that it is shorter for no good reason. It is shorter because the short form is clearer and faster to understand, without sacrificing any useful information. > If you were to reject the > use of "returnValue" in favor of "ret" then... well, it's better I > don't continue this sentence. > I'd likely reject the use of "ret" as well - it is a poor choice of name, and gives little useful information. But it is not as bad as "returnValue", which is useless /and/ long and therefore a waste of brain power. >> 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. > > There's zero reason to make the name more cryptic than it has to be. > There's zero reason to think that obvious names are cryptic. > You are now just arguing for the sake of arguing, and it makes no sense. > I honestly cannot understand why this is so controversial and deserving > of such strong opposition. It feels like I have been suggesting to use > profanity, swearwords and politically offensive terminology in variable > and function names. > No, you are just suggesting a waste of effort and bad habits that make code harder to read. Look, I appreciate the challenge of dealing with code that is cryptic and has poor choice of identifiers. There are many ways identifiers can be done badly - overly short names and with inappropriate abbreviations is certainly one such way. But equally, overly /long/ names that are cumbersome, repetitive, and distract from important information is another way to write incomprehensible code. You go too far in that direction. Like most things in life, the ideal is a happy medium, and the details depend on the circumstances. >> 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? > > There we go again with the length argument. > > How many times do I have to repeat this? You seem to believe in proof by repeated assertion - I've heard no other justification for your arguments. > IT'S NOT ABOUT LENGTH! > It's about legibility and understandability. I know that. We all know that. It is best to use "i" as an index in a "for" loop, unless you have good reason for picking something else, because it is entirely clear to the reader what "i" is. Writing "index" is worse - no one knows what it is, other than an index into some container, and you have to look and think to see where it comes from. Being a longer name, the obvious thought is that it comes from further away earlier in the code, or will be used further away later in the code, rather than being a very local "for" loop counter. Even if you have the same associations for "i" and "index", "i" is better because it is shorter. Shorter means faster to process, less effort, and less distraction from the rest of the code. It is not about length - it is about being clearer, easier to read, and easier to understand. In this case, being shorter is a factor that makes it clearer and more legible. And yes, we all agree that often "average" is better than "avr" because it is clearer and unambiguous, and thereby easier to read despite being longer. No one is arguing that short is always better. However, when I say "short is /sometimes/ better, or at least not worse" (as in the case of a loop variable), and you disagree, the logic of your disagreement is that "longer is always better". Perhaps you don't realise you are claiming that, but you are. If you don't think that "longer is /always/ better", then you are actually in agreement with what others have said all along. > Sometimes increased > legibility makes names longer, but that's just an irrelevant side > effect. The length itself is not the primary goal. > > How hard is that to understand, honestly? I understand what you are saying. I don't think /you/ do.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-12-12 09:38 -0800 |
| Message-ID | <6a848ae6-95f3-4b8b-bf9f-612d98480a5bn@googlegroups.com> |
| In reply to | #87829 |
On Monday, December 12, 2022 at 5:11:55 PM UTC+2, David Brown wrote: > On 12/12/2022 12:31, Juha Nieminen wrote: > > You write the same words in your English prose again and again and again. > > You don't see that as a problem. Why do you find it a problem in code? > > Of course it can be a problem in prose. It can make the prose tedious > and therefore harder to read. Marcus Tullius Cicero commonly considered a brilliant stylist, may be, GOAT. I mean, by those who had read his writings, a group to which I don't belong. Repetitions (periodic style) are one of his favorite tools. However both Marcus Antonius and Marcus Aemilius Lepidus thought that his style is tedious and convinced Octavian that Cicero has to be murdered.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-12 16:32 +0000 |
| Message-ID | <87pmco4m7v.fsf@bsb.me.uk> |
| In reply to | #87819 |
Juha Nieminen <nospam@thanks.invalid> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> It's usually more enlightening to give what you consider good and bad >> examples as well some examples on the boundary. For example, I rarely >> want to know more about the type when I see >> >> for (const auto &elem : <something>) ... > > I find it quite strange that you aren't interested in what that element > type is. I think this captures the heart of the disagreement. In well-written code, I would hope to not care. If the exact type of what this loop is iterating over is crucial to understanding the loop or verifying that the loop does what it should, then I would want to change the other code, not the type in the loop. But then I like to program (full disclosure: for fun only these days) in Haskell which has, to all intents and purposes, a default auto. Types are almost always inferred rather than stated. > When you know nothing about the type, you have no way of > knowing what to expect in the subsequent lines of code. Looking at > that line alone it may be completely unclear what it's actually doing > (depending on what that <something> is). > > Compare it to, say: > > for (const std::string& elem: <something>) > > Aha! Now we know a lot more about what <something> is, and what to > expect in subsequent lines of code. Just that one little change is > giving us a lot more information and clarity about what's happening > here. I would hope that knowing the type is not needed for verifying what the loop is doing but I am aware that code is not always that well organised. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-13 08:13 -0800 |
| Message-ID | <93062c4f-a444-4ada-a5df-dc7827bacf46n@googlegroups.com> |
| In reply to | #87832 |
On Monday, December 12, 2022 at 11:32:20 AM UTC-5, Ben Bacarisse wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>
> But then I like to program (full disclosure: for fun only these days) in
> Haskell which has, to all intents and purposes, a default auto. Types
> are almost always inferred rather than stated.
But in Haskell cases like this can't arise:
std::vector<bool> v = { true,false,true };
auto value = v[1];
value = true;
assert(v[1] == false); // fails
Were Juha were to inherit a C++ code base that made significant use of matrix
libraries, or was written by programmers that had read Scott Meyers' Effective
C++ series, and that was also liberally sprinkled with auto, he would have
to put some effort into convincing himself that it didn't have "auto value =
copy of proxy" landmines.
Daniel
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-13 17:16 +0000 |
| Message-ID | <tnac0p$vfr$1@gioia.aioe.org> |
| In reply to | #87873 |
On Tue, 13 Dec 2022 08:13:37 -0800 (PST)
"daniel...@gmail.com" <danielaparker@gmail.com> wrote:
>On Monday, December 12, 2022 at 11:32:20 AM UTC-5, Ben Bacarisse wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>> But then I like to program (full disclosure: for fun only these days) in
>> Haskell which has, to all intents and purposes, a default auto. Types
>> are almost always inferred rather than stated.
>
>But in Haskell cases like this can't arise:
>
> std::vector<bool> v = { true,false,true };
> auto value = v[1];
> value = true;
> assert(v[1] == false); // fails
This is something I've never thought about. So when does auto default to a
reference? Because if you change that to an int it doesn't assert eg:
std::vector<int> v = { 1,2,3 };
auto value = v[1];
value = 4;
assert(v[1] == 2);
So in the case of bool its taking a reference, but in the case of int its
doing a copy.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-13 11:10 -0800 |
| Message-ID | <94f6f221-7a36-429f-87e9-faad2f27710en@googlegroups.com> |
| In reply to | #87874 |
On Tuesday, December 13, 2022 at 12:16:26 PM UTC-5, Mut...@dastardlyhq.com wrote:
> On Tue, 13 Dec 2022 08:13:37 -0800 (PST)
> "daniel...@gmail.com" <daniel...@gmail.com> wrote:
> >On Monday, December 12, 2022 at 11:32:20 AM UTC-5, Ben Bacarisse wrote:
> >> Juha Nieminen <nos...@thanks.invalid> writes:
> >>
> >> But then I like to program (full disclosure: for fun only these days) in
> >> Haskell which has, to all intents and purposes, a default auto. Types
> >> are almost always inferred rather than stated.
> >
> >But in Haskell cases like this can't arise:
> >
> > std::vector<bool> v = { true,false,true };
> > auto value = v[1];
> > value = true;
> > assert(v[1] == false); // fails
> This is something I've never thought about. So when does auto default to a
> reference? Because if you change that to an int it doesn't assert eg:
bool isSomething = false;
auto val = isSomething ; // value
auto& ref = isSomething ; // reference
Same as for int.
That isn't the issue here. The issue is that the index operator for std::vector<bool>
returns a proxy rather than the value of a bool. So value1 and value2 in
auto value1 = v[1];
bool value2 = v[1];
are both values, but different. Mutating value1 has side effects, mutating value2 does not.
Daniel
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-14 09:33 +0000 |
| Message-ID | <tnc59i$qp5$1@gioia.aioe.org> |
| In reply to | #87875 |
On Tue, 13 Dec 2022 11:10:27 -0800 (PST)
"daniel...@gmail.com" <danielaparker@gmail.com> wrote:
>On Tuesday, December 13, 2022 at 12:16:26 PM UTC-5, Mut...@dastardlyhq.com
>wrote:
>> On Tue, 13 Dec 2022 08:13:37 -0800 (PST)
>> "daniel...@gmail.com" <daniel...@gmail.com> wrote:
>> >On Monday, December 12, 2022 at 11:32:20 AM UTC-5, Ben Bacarisse wrote:
>> >> Juha Nieminen <nos...@thanks.invalid> writes:
>> >>
>> >> But then I like to program (full disclosure: for fun only these days) in
>> >> Haskell which has, to all intents and purposes, a default auto. Types
>> >> are almost always inferred rather than stated.
>> >
>> >But in Haskell cases like this can't arise:
>> >
>> > std::vector<bool> v = { true,false,true };
>> > auto value = v[1];
>> > value = true;
>> > assert(v[1] == false); // fails
>> This is something I've never thought about. So when does auto default to a
>> reference? Because if you change that to an int it doesn't assert eg:
>
>bool isSomething = false;
>auto val = isSomething ; // value
>auto& ref = isSomething ; // reference
>
>Same as for int.
>
>That isn't the issue here. The issue is that the index operator for
>std::vector<bool>
>returns a proxy rather than the value of a bool. So value1 and value2 in
>
>auto value1 = v[1];
>
>bool value2 = v[1];
>
>are both values, but different. Mutating value1 has side effects, mutating
>value2 does not.
IOW the auto type can differ from expectations.
TBH I've always avoided vector<bool> because of its specialisation. This is
another reason not to use it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-14 14:16 +0100 |
| Message-ID | <tncibe$2q2at$2@dont-email.me> |
| In reply to | #87890 |
On 14/12/2022 10:33, Muttley@dastardlyhq.com wrote:
> On Tue, 13 Dec 2022 11:10:27 -0800 (PST)
> "daniel...@gmail.com" <danielaparker@gmail.com> wrote:
>> On Tuesday, December 13, 2022 at 12:16:26 PM UTC-5, Mut...@dastardlyhq.com
>> wrote:
>>> On Tue, 13 Dec 2022 08:13:37 -0800 (PST)
>>> "daniel...@gmail.com" <daniel...@gmail.com> wrote:
>>>> On Monday, December 12, 2022 at 11:32:20 AM UTC-5, Ben Bacarisse wrote:
>>>>> Juha Nieminen <nos...@thanks.invalid> writes:
>>>>>
>>>>> But then I like to program (full disclosure: for fun only these days) in
>>>>> Haskell which has, to all intents and purposes, a default auto. Types
>>>>> are almost always inferred rather than stated.
>>>>
>>>> But in Haskell cases like this can't arise:
>>>>
>>>> std::vector<bool> v = { true,false,true };
>>>> auto value = v[1];
>>>> value = true;
>>>> assert(v[1] == false); // fails
>>> This is something I've never thought about. So when does auto default to a
>>> reference? Because if you change that to an int it doesn't assert eg:
>>
>> bool isSomething = false;
>> auto val = isSomething ; // value
>> auto& ref = isSomething ; // reference
>>
>> Same as for int.
>>
>> That isn't the issue here. The issue is that the index operator for
>> std::vector<bool>
>> returns a proxy rather than the value of a bool. So value1 and value2 in
>>
>> auto value1 = v[1];
>>
>> bool value2 = v[1];
>>
>> are both values, but different. Mutating value1 has side effects, mutating
>> value2 does not.
>
> IOW the auto type can differ from expectations.
>
> TBH I've always avoided vector<bool> because of its specialisation. This is
> another reason not to use it.
>
Yes, the problem here is that a std::vector<bool> behaves significantly
differently from all other std::vector types. The intention of the STL
(as it was called in those days) developers was to make something that
is efficient, compact, and as simple to use as other vector types. They
did a reasonable job, but the result is inconsistent and surprising in
some ways. I would much preferred inefficiency and consistency, and a
separate type ("bit_vector") for compactness.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 08:58 +0000 |
| Message-ID | <tnp92r$f4e$1@gioia.aioe.org> |
| In reply to | #87905 |
David Brown <david.brown@hesbynett.no> wrote:
> Yes, the problem here is that a std::vector<bool> behaves significantly
> differently from all other std::vector types. The intention of the STL
> (as it was called in those days) developers was to make something that
> is efficient, compact, and as simple to use as other vector types. They
> did a reasonable job, but the result is inconsistent and surprising in
> some ways. I would much preferred inefficiency and consistency, and a
> separate type ("bit_vector") for compactness.
Yeah, in retrospect it may have been better if they had kept std::vector
with a single implementation without a separate specialization for bool,
and instead created an entirely different class for handling a dynamic
array of bits.
Well, at least std::vector<bool> doesn't come with 87.5% wasted space,
which is a positive.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-19 15:20 +0100 |
| Message-ID | <tnprug$c0l9$2@dont-email.me> |
| In reply to | #88030 |
On 19/12/2022 09:58, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> Yes, the problem here is that a std::vector<bool> behaves significantly
>> differently from all other std::vector types. The intention of the STL
>> (as it was called in those days) developers was to make something that
>> is efficient, compact, and as simple to use as other vector types. They
>> did a reasonable job, but the result is inconsistent and surprising in
>> some ways. I would much preferred inefficiency and consistency, and a
>> separate type ("bit_vector") for compactness.
>
> Yeah, in retrospect it may have been better if they had kept std::vector
> with a single implementation without a separate specialization for bool,
> and instead created an entirely different class for handling a dynamic
> array of bits.
>
> Well, at least std::vector<bool> doesn't come with 87.5% wasted space,
> which is a positive.
I'd rather have the wasted space than the inconsistency, and then have
an alternative type with a more appropriate interface and
space-efficient implementation. I don't want compromise, I want both
possibilities.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-14 11:54 +0000 |
| Message-ID | <87wn6u19qn.fsf@bsb.me.uk> |
| In reply to | #87873 |
"daniel...@gmail.com" <danielaparker@gmail.com> writes:
> On Monday, December 12, 2022 at 11:32:20 AM UTC-5, Ben Bacarisse wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>> But then I like to program (full disclosure: for fun only these days) in
>> Haskell which has, to all intents and purposes, a default auto. Types
>> are almost always inferred rather than stated.
>
> But in Haskell cases like this can't arise:
>
> std::vector<bool> v = { true,false,true };
> auto value = v[1];
> value = true;
> assert(v[1] == false); // fails
That "fail" is so obvious that I think there must be a better example of
something that will baffle the reader.
Is a wide-spread idiom in which some aggregate accessory (like
operator[]) really returns something that behaves like a reference but
which is defeated by the use of auto?
> Were Juha were to inherit a C++ code base that made significant use of matrix
> libraries, or was written by programmers that had read Scott Meyers' Effective
> C++ series, and that was also liberally sprinkled with auto, he would have
> to put some effort into convincing himself that it didn't have "auto value =
> copy of proxy" landmines.
Can you give a cut-down example? I can't shake the feeling that the
problem might not be with auto, but with the idiom that is defeated by
using auto. (Not that I want to defend all uses of auto. C++'s types
are so potentially baroque and open to abuse that knowing the exact type
might very well be beneficial at times.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-14 09:40 -0800 |
| Message-ID | <fb01d359-73db-45ec-a16a-fa209767351en@googlegroups.com> |
| In reply to | #87899 |
On Wednesday, December 14, 2022 at 6:54:41 AM UTC-5, Ben Bacarisse wrote:
> "daniel...@gmail.com" <daniel...@gmail.com> writes:
>
> > But in Haskell cases like this can't arise:
> >
> > std::vector<bool> v = { true,false,true };
> > auto value = v[1];
> > value = true;
> > assert(v[1] == false); // fails
> That "fail" is so obvious that I think there must be a better example of
> something that will baffle the reader.
Is it so obvious? I would have thought a typical C++ programmer
would expect bare auto to never deduce a reference. But here
it seemingly does.
In any case, the example wasn't designed to baffle the reader,
but to illustrate the problem of using auto in conjunction with functions
returning proxy values invoking only the standard library.
>
> Is a wide-spread idiom in which some aggregate accessory (like
> operator[]) really returns something that behaves like a reference but
> which is defeated by the use of auto?
It certainly is in numerical libraries such as Eigen and Armadillo , which use
return proxies extensively, particularly for functions and operators returning matrices
(to avoid unnecessary copies). Elsewhere, in pre-auto days Scott Meyers popularized
the use of proxy return types in his series of Effective C++ books. They're not
that rare, including as noted one instance in the standard library.
> > Were Juha were to inherit a C++ code base that made significant use of matrix
> > libraries, or was written by programmers that had read Scott Meyers' Effective
> > C++ series, and that was also liberally sprinkled with auto, he would have
> > to put some effort into convincing himself that it didn't have "auto value =
> > copy of proxy" landmines.
> Can you give a cut-down example?
See link below. Regarding the potential landmines of using proxy objects ,
ones I've seen include expecting a value type but getting reference semantics
(as illustrated above), acquiring a complex proxy object where member
functions perform expensive lookups for every call, and acquiring objects
that hold pointers to memory that is past the continuation point.
>I can't shake the feeling that the
> problem might not be with auto, but with the idiom that is defeated by
> using auto.
As noted, the idiom is firmly entrenched in numerical libraries, particularly
in implementations of expression templates.
Proxies and auto don't interact well, because auto exposes aspects of
the type that were meant to stay hidden. There have been suggestions
for a language change, where the auto in auto v = foo() or auto& v = foo()
can be deduced as the value type, even if foo() returns a proxy value, see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf.
In the meantime, it might be prudent to exercise some caution in the use of auto,
and not to blindly use it everywhere.
Daniel
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-14 22:15 +0000 |
| Message-ID | <87ilid1vko.fsf@bsb.me.uk> |
| In reply to | #87923 |
"daniel...@gmail.com" <danielaparker@gmail.com> writes:
> On Wednesday, December 14, 2022 at 6:54:41 AM UTC-5, Ben Bacarisse wrote:
>> "daniel...@gmail.com" <daniel...@gmail.com> writes:
>>
>> > But in Haskell cases like this can't arise:
>> >
>> > std::vector<bool> v = { true,false,true };
>> > auto value = v[1];
>> > value = true;
>> > assert(v[1] == false); // fails
>
>> That "fail" is so obvious that I think there must be a better example of
>> something that will baffle the reader.
>
> Is it so obvious? I would have thought a typical C++ programmer
> would expect bare auto to never deduce a reference. But here
> it seemingly does.
Thank you! This is an excellent example because, looking more closely,
I ended up flip-flopping between "of course" and "eh?" until I saw why
you'd chosen it.
My initial "it's obvious" was correct but for all the wrong reasons.
Auto will not normally infer a reference even though operator[]'s return
type is a reference type. But the special return type required by
std::vector<bool> alters that. That type is not a C++ reference type
but a std::vector<bool>::reference. Auto must, of course, infer that
special object type.
> In any case, the example wasn't designed to baffle the reader,
> but to illustrate the problem of using auto in conjunction with functions
> returning proxy values invoking only the standard library.
And, when I looked at it properly, it did that.
>> > Were Juha were to inherit a C++ code base that made significant use
>> > of matrix libraries, or was written by programmers that had read
>> > Scott Meyers' Effective C++ series, and that was also liberally
>> > sprinkled with auto, he would have to put some effort into
>> > convincing himself that it didn't have "auto value = copy of proxy"
>> > landmines.
>
>> Can you give a cut-down example?
>
> See link below.
Thanks, but also see above. I entirely missed that you'd used
std::vector<bool> for a reason.
> Proxies and auto don't interact well, because auto exposes aspects of
> the type that were meant to stay hidden. There have been suggestions
> for a language change, where the auto in auto v = foo() or auto& v = foo()
> can be deduced as the value type, even if foo() returns a proxy value, see
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf.
Hmm... It seems to me that the problem here (in terms of readability)
is not really auto but the desire of the programmer to have pretty
matrix product expressions at the expense of hiding what's really going
on. In that sense, std::vector<bool> falls into the same trap. It's
neat, but it's too easy to overlook what's under the hood.
> In the meantime, it might be prudent to exercise some caution in the
> use of auto, and not to blindly use it everywhere.
Indeed.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-15 10:34 +0100 |
| Message-ID | <tnepmu$32d2b$1@dont-email.me> |
| In reply to | #87939 |
On 14/12/2022 23:15, Ben Bacarisse wrote: > "daniel...@gmail.com" <danielaparker@gmail.com> writes: >> In the meantime, it might be prudent to exercise some caution in the >> use of auto, and not to blindly use it everywhere. > > Indeed. > I think that applies to pretty much anything in programming. C++ has /lots/ of features, and they lot you do a great deal in your code. Overuse or "blind" use is always a big risk, especially if you are dealing with more complicated code. (Advanced matrix libraries with expression templates at least /look/ complicated - std::vector<bool> is more deceptive.) On the other hand, avoiding features like "auto" just because they can /sometimes/ be confusing or misused is going to mean missed opportunities for writing better code - clearer, neater, more general, more efficient. Taken to its logical conclusion, if you avoid features that can be abused you're going to throw out almost everything in the language!
[toc] | [prev] | [next] | [standalone]
Page 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web