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 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-12-09 13:05 -0800 |
| Message-ID | <86pmcs47at.fsf@linuxsc.com> |
| In reply to | #87775 |
Juha Nieminen <nospam@thanks.invalid> writes: > Tiib <ootiib@hot.ee> wrote: > >> Yes but it is tedious. Some types are *LONG*, especially what templates >> can return. > > So what? I very much oppose the brevity-over-clarity style of > programming. There is a tacit assumption in that statement that longer is always easier to read or more readily comprehended. The assumption is wrong. Good writers appreciate the difference between lengthy phrasing and concise phrasing, using each as appropriate, and varying wording choices between the two, to make their writing more effective. That advice applies to programming as much as it does to writing prose.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-12 07:04 +0000 |
| Message-ID | <tn6jpo$d6c$2@gioia.aioe.org> |
| In reply to | #87787 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Juha Nieminen <nospam@thanks.invalid> writes: > >> Tiib <ootiib@hot.ee> wrote: >> >>> Yes but it is tedious. Some types are *LONG*, especially what templates >>> can return. >> >> So what? I very much oppose the brevity-over-clarity style of >> programming. > > There is a tacit assumption in that statement that longer is > always easier to read or more readily comprehended. No, there isn't. Overly short being hard to read does not mean that overly long is easy to read. Overly long can perfectly well *also* be hard to read. You have to reach the optimal middle: Not too short, not too long. The name must convey clearly its meaning. If you make it too compressed or too sparse, it becomes harder to discern this meaning. The problem I see in 99.99% of programming is that people tend to always go with the overly short, usually for no reason whatsoever.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-12-28 12:25 -0800 |
| Message-ID | <86k02buvgu.fsf@linuxsc.com> |
| In reply to | #87817 |
Juha Nieminen <nospam@thanks.invalid> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Juha Nieminen <nospam@thanks.invalid> writes: >> >>> Tiib <ootiib@hot.ee> wrote: >>> >>>> Yes but it is tedious. Some types are *LONG*, especially what templates >>>> can return. >>> >>> So what? I very much oppose the brevity-over-clarity style of >>> programming. >> >> There is a tacit assumption in that statement that longer is >> always easier to read or more readily comprehended. > > No, there isn't. Of course there is. The phrase "brevity-over-clarity" suggests a false dichotomy between brief and clear. Anyone who pretends otherwise is just being obtuse.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-29 20:27 +0000 |
| Message-ID | <tokt7t$bqr$1@gioia.aioe.org> |
| In reply to | #88280 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Juha Nieminen <nospam@thanks.invalid> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> Juha Nieminen <nospam@thanks.invalid> writes: >>> >>>> Tiib <ootiib@hot.ee> wrote: >>>> >>>>> Yes but it is tedious. Some types are *LONG*, especially what templates >>>>> can return. >>>> >>>> So what? I very much oppose the brevity-over-clarity style of >>>> programming. >>> >>> There is a tacit assumption in that statement that longer is >>> always easier to read or more readily comprehended. >> >> No, there isn't. > > Of course there is. The phrase "brevity-over-clarity" suggests > a false dichotomy between brief and clear. Anyone who pretends > otherwise is just being obtuse. No. "Brevity over clarity" does not mean "longer is always more readable". It means "shortening words at the cost of legibility." There is a difference. A word doesn't become more legible if it's longer. If a word is three letters long, and fully and easily understandable as it is, there's no reason to use anything longer. A longer word doesn't necessarily make it more legible. The problem is that it's extraordinarily common for programmers to take words and abbreviate them or form acronyms with them for no reason, at the cost of legibility. The legibility does not decrease because the names become shorter. The legibility decreases because information is removed from the words. It's not about the length, it's about the information content and how easy it is to understand. "Verbosity-over-clarity" would also be a perfectly valid concept and something to oppose. It's just that almost no programmer succumbs to such a thing. Do you understand now? It's not about length. It's about legibility.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2022-12-09 15:25 -0600 |
| Message-ID | <tn094u$1b54o$1@dont-email.me> |
| In reply to | #87753 |
On 12/8/2022 6:31 AM, Juha Nieminen wrote: > During the last few years I have had to read an inordinate amount of > code written by other people. It has really given me a big insight on > what makes code more and less readable and understandable. For example, > I could write an entire book on naming conventions alone, and how they > can make the code so much more readable, or make it almost inscrutable. > > But another thing I have really learned to hate is the overuse of the > 'auto' keyword. I have always opposed its needless overuse, but this > couple of years of reading other people's code has really confirmed > and cemented my previous opinion on it. > > Some C++ programmers do not use 'auto' merely to save some typing, > as some kind of convenience feature. They go their way to use it > pretty much everywhere they can, even when it doesn't actually save > any typing or make anything more convenient. They use it like it were > the generic variable declaration keyword in many other languages > (quite typically "var"). > > The problem in using 'auto' everywhere, from the perspective of someone > who is reading the code, is that it hides the type in question. When > you see something like: > > auto foobar = someFunction(a, b); > > it's a complete mystery what that return type is, and thus the reader > (ie. me) has no idea what it actually is, what it does, and how it's > used. Could be an 'int', could be a 'double', could be a 'std::string', > or could be a custom type declared somewhere else in the program. That > line alone doesn't clarify. Quite often even subsequent lines of code > don't necessarily clarify. > > It just makes code so much harder to read when this crucial information > has been hidden from you. This is not really what "information hiding" > should be about. > > "Yada yada! Just use an IDE like everybody else does!" > > Even putting aside the fact that well-written code shouldn't rely on the > reader using an IDE to understand it, there are many situations where > you don't have a fancy IDE to tell you what that type is, or where it > can be found, such as for example when reading and reviewing the code > in gitlab. Try reviewing code when you can't even see what the types > being used are. > > Man, have I learned to hate the overuse of 'auto'... Amen, brother ! Preach on ! Lynn
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2022-12-10 16:29 +0100 |
| Message-ID | <tn28l4$1m4iu$1@dont-email.me> |
| In reply to | #87753 |
Am 08.12.22 um 13:31 schrieb Juha Nieminen:
> The problem in using 'auto' everywhere, from the perspective of someone
> who is reading the code, is that it hides the type in question. When
> you see something like:
>
> auto foobar = someFunction(a, b);
>
> it's a complete mystery what that return type is, and thus the reader
> (ie. me) has no idea what it actually is, what it does, and how it's
> used.
My question to you: why do you need to know the type of foobar in thie -
s case? Have you used dynamic languages like e.g. Python? THere the line
would read:
foobar = someFunction(a, b);
This has never be a big problem when writing Python code. "someFunction"
is a bad description of the return value, that is the problem here. You
wouldn't have the same difficulty to read:
auto x = concat("abc", "123");
or
auto d = sqrt(x**2 + y**2);
Christian
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-10 15:39 -0800 |
| Message-ID | <e7381014-f71a-4152-8ab6-55a4b2126a1en@googlegroups.com> |
| In reply to | #87799 |
On Saturday, December 10, 2022 at 10:29:59 AM UTC-5, Christian Gollwitzer wrote: > Am 08.12.22 um 13:31 schrieb Juha Nieminen: > > > > auto foobar = someFunction(a, b); > > > why do you need to know the type of foobar in thie - > s case? Minimally, you need to know whether someFunction returns a proxy, if it does, you don't want to use auto. Functions returning proxies aren't that rare in C++, matrix libraries such as Eigen use them extensively, and there's even one in the standard library. > > This has never be a big problem when writing Python code But Python is a more coherent language than C++. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-12 07:10 +0000 |
| Message-ID | <tn6k4m$lfc$1@gioia.aioe.org> |
| In reply to | #87799 |
Christian Gollwitzer <auriocus@gmx.de> wrote:
> Am 08.12.22 um 13:31 schrieb Juha Nieminen:
>> The problem in using 'auto' everywhere, from the perspective of someone
>> who is reading the code, is that it hides the type in question. When
>> you see something like:
>>
>> auto foobar = someFunction(a, b);
>>
>> it's a complete mystery what that return type is, and thus the reader
>> (ie. me) has no idea what it actually is, what it does, and how it's
>> used.
>
> My question to you: why do you need to know the type of foobar in thie -
> s case?
Because it helps me understand what that is doing, and what subsequent
lines are doing. There's quite a difference whehter that return type is
an int, a const char*, or a std::string, and if the return type is
specified right there, it immediately helps me understand what's
happening. The 'auto' tells me *absolutely nothing* about what's
happening there.
When 'auto' is used, the subsequent lines don't necessarily help me
know what that type is. Is it an 'int'? An 'unsigned int'? A 'double'?
A 'float'? Subsequent lines don't necessarily help me see which one
of those it is, or perhaps some other similar type. This information
is hidden from this piece of code, for no good reason.
> This has never be a big problem when writing Python code. "someFunction"
> is a bad description of the return value, that is the problem here. You
> wouldn't have the same difficulty to read:
>
> auto x = concat("abc", "123");
Does it return a const char*, or a std::string, or perhaps something else?
That's quite a big difference.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-12 09:49 +0100 |
| Message-ID | <tn6pui$26km1$1@dont-email.me> |
| In reply to | #87818 |
On 12/12/2022 08:10, Juha Nieminen wrote:
> Christian Gollwitzer <auriocus@gmx.de> wrote:
>> Am 08.12.22 um 13:31 schrieb Juha Nieminen:
>>> The problem in using 'auto' everywhere, from the perspective of someone
>>> who is reading the code, is that it hides the type in question. When
>>> you see something like:
>>>
>>> auto foobar = someFunction(a, b);
>>>
>>> it's a complete mystery what that return type is, and thus the reader
>>> (ie. me) has no idea what it actually is, what it does, and how it's
>>> used.
>>
>> My question to you: why do you need to know the type of foobar in thie -
>> s case?
>
> Because it helps me understand what that is doing, and what subsequent
> lines are doing. There's quite a difference whehter that return type is
> an int, a const char*, or a std::string, and if the return type is
> specified right there, it immediately helps me understand what's
> happening. The 'auto' tells me *absolutely nothing* about what's
> happening there.
>
> When 'auto' is used, the subsequent lines don't necessarily help me
> know what that type is. Is it an 'int'? An 'unsigned int'? A 'double'?
> A 'float'? Subsequent lines don't necessarily help me see which one
> of those it is, or perhaps some other similar type. This information
> is hidden from this piece of code, for no good reason.
>
>> This has never be a big problem when writing Python code. "someFunction"
>> is a bad description of the return value, that is the problem here. You
>> wouldn't have the same difficulty to read:
>>
>> auto x = concat("abc", "123");
>
> Does it return a const char*, or a std::string, or perhaps something else?
> That's quite a big difference.
I don't think anyone will disagree with you that manual typing is better
than "auto" when the exact type matters and it is not clear from the
context. But often the type details /don't/ matter, or they /are/ clear
from the context - and then "auto" is fine.
It's not really any different from all sorts of other aspects of
programming - you always have a balance between being explicit and
wordy, or being implicit and simpler.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-12 11:35 +0000 |
| Message-ID | <tn73l7$1i5e$2@gioia.aioe.org> |
| In reply to | #87822 |
David Brown <david.brown@hesbynett.no> wrote: > I don't think anyone will disagree with you that manual typing is better > than "auto" when the exact type matters and it is not clear from the > context. But often the type details /don't/ matter, or they /are/ clear > from the context - and then "auto" is fine. That sounds good in theory. In practice not so much. As mentioned, I have learned the hate the over-use of 'auto' through the process of having to read tends of thousands of lines of code written by other people. Quite often even in situations where in theory "the type doesn't matter", it makes reading the code more difficult precisely because you don't know what type it is and why it "doesn't matter". It makes the code harder to understand because you don't know what it's dealing with. Sometimes that's ok (such as in templated code). Sometimes it isn't.
[toc] | [prev] | [next] | [standalone]
| From | Udo Steinbach <trashcan@udoline.de> |
|---|---|
| Date | 2022-12-14 20:03 +0100 |
| Message-ID | <tnd6lk$2rnmj$1@dont-email.me> |
| In reply to | #87822 |
Am 2022-12-12 um 09:49 schrieb David Brown: > when the exact type matters This is the keyword. A security man who has to audit your code needs the exact type of everything and you have to pay for every over-shorting, every ambiguity, and for every single auto. Maybe that your collegue knows about the types and names. But he or you pays with time, if not, if he misunderstands, overlooks a little thing. http://blog.fefe.de/?ts=a0cf97c9 about C++ auto „Then the poor auditor has to run after each crappy line one by one and derive the types himself.“ -- Fahrradverkehr in Deutschland: http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-14 20:18 +0100 |
| Message-ID | <tnd7hl$2rmfq$3@dont-email.me> |
| In reply to | #87930 |
On 14/12/2022 20:03, Udo Steinbach wrote: > Am 2022-12-12 um 09:49 schrieb David Brown: >> when the exact type matters > > This is the keyword. A security man who has to audit your code needs the > exact type of everything and you have to pay for every over-shorting, > every ambiguity, and for every single auto. Maybe that your collegue knows > about the types and names. But he or you pays with time, if not, if he > misunderstands, overlooks a little thing. > Anyone trying to audit code one line at a time is doing it wrong. Anyone who thinks they can see the types of everything by looking at the line using it is living in a dream world (or more accurately, a nightmare world). If I write "int x = a * b;", what are the exact types of "a" and "b" ? You don't know. You'll have to look at their declarations to see. But maybe it's enough to know they are types whose product can be implicitly converted to an "int". If I write "int x = foo(y);", what are all the types involved? You don't know. More importantly, you don't know what "y" is (even if it had a fuller name), when it is set, what values it has, or how it is used. You don't know what "foo" does (again, even if it had a fuller name). You don't know if it has side-effects or is "pure", you don't know the parameter type, or the return type, or if it is overloaded, or if it is in a namespace, or if it is a "friend" of the class of "y". After all, the type of something is only one aspect of it. Basically, you know sod all by looking at the line alone. You have to look at the /program/. In a well-written program, you won't have to look far, and you can use the names of any distant identifiers as a clue to what they are (while nearby identifiers can have short names because their definitions are close). But normal use of "auto" is a drop in the ocean here. > http://blog.fefe.de/?ts=a0cf97c9 about C++ auto > „Then the poor auditor has to run after each crappy line one by one and > derive the types himself.“
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 09:06 +0000 |
| Message-ID | <tnp9ih$mmu$1@gioia.aioe.org> |
| In reply to | #87932 |
David Brown <david.brown@hesbynett.no> wrote: > If I write "int x = a * b;", what are the exact types of "a" and "b" ? > You don't know. You'll have to look at their declarations to see. But > maybe it's enough to know they are types whose product can be implicitly > converted to an "int". While it's not perfect, at least it's better than "auto x = a * b;" because at least you have *some* information, which is better than none. Incidentally, naming those variables more clearly could also help understanding better that line of code. For example, if the variables were named "row_index" and "table_width", suddenly that line becomes extraordinarily clearer than if they are just "a" and "b". > If I write "int x = foo(y);", what are all the types involved? You > don't know. Here, too, naming the function and the variables more clearly may help understanding better what that line is doing and what the variables and their types are. Which is my entire point in this thread.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-19 15:39 +0100 |
| Message-ID | <tnpt3v$c4c4$1@dont-email.me> |
| In reply to | #88031 |
On 19/12/2022 10:06, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> If I write "int x = a * b;", what are the exact types of "a" and "b" ?
>> You don't know. You'll have to look at their declarations to see. But
>> maybe it's enough to know they are types whose product can be implicitly
>> converted to an "int".
>
> While it's not perfect, at least it's better than "auto x = a * b;"
> because at least you have *some* information, which is better than none.
>
Why is it better? Why do you care what type it is? Surely the
important thing about "x" is that it is the result of multiplying "a"
and "b", not its type. If you use "auto", you know that type is correct
for its use here - if you use "int", it might not be.
Good, legible programming is about making the important information
clear - not about making all details clear at all points in the code.
> Incidentally, naming those variables more clearly could also help
> understanding better that line of code. For example, if the variables
> were named "row_index" and "table_width", suddenly that line becomes
> extraordinarily clearer than if they are just "a" and "b".
>
I don't care about the clarity of the line. I care about the clarity of
the /code/. Do you understand the difference?
const auto b = table.width();
for (auto a = 0; a < table.row_count(); a++) {
auto x = a * b;
...
The code in question is /clearer/ than using "row_index" and
"table_width" would be, because it is simple and quick to parse
mentally, and all the relevant information about "a" and "b" is
immediately available. ("w" and "i" would be better than "b" and "a",
of course. And we don't know if "x" is a good name without seeing the
following code.)
Clarity is for /code/, not for /lines/.
>> If I write "int x = foo(y);", what are all the types involved? You
>> don't know.
>
> Here, too, naming the function and the variables more clearly may help
> understanding better what that line is doing and what the variables and
> their types are.
>
> Which is my entire point in this thread.
So you are in agreement that you don't know the types of the variables
or functions in use, without their context. The logical implication is
that using "auto" is not some terrible sin that destroys the readability
of code - really, it is just a minor issue compared to good naming.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-19 07:10 -0800 |
| Message-ID | <931a026e-6429-471f-8bd6-0ea8d2647b9dn@googlegroups.com> |
| In reply to | #88047 |
On Monday, December 19, 2022 at 9:40:14 AM UTC-5, David Brown wrote: > > While it's not perfect, at least it's better than "auto x = a * b;" > > because at least you have *some* information, which is better than none. > > > Why is it better? Why do you care what type it is? Surely the > important thing about "x" is that it is the result of multiplying "a" > and "b", not its type. If you use "auto", you know that type is correct > for its use Actually you don't if 'a' and 'b' are matrices and 'a*b' returns a proxy object, as a numerical library would do. In other languages you could make that claim about 'var x = a*b', but in C++ it needs to be qualified, in some contexts the type is correct for its use, in others it's undefined behavior. Daniel
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-20 13:46 +0100 |
| Message-ID | <tnsarg$mhb6$1@dont-email.me> |
| In reply to | #88049 |
On 19/12/2022 16:10, daniel...@gmail.com wrote: > On Monday, December 19, 2022 at 9:40:14 AM UTC-5, David Brown wrote: >>> While it's not perfect, at least it's better than "auto x = a * b;" >>> because at least you have *some* information, which is better than none. >>> >> Why is it better? Why do you care what type it is? Surely the >> important thing about "x" is that it is the result of multiplying "a" >> and "b", not its type. If you use "auto", you know that type is correct >> for its use > > Actually you don't if 'a' and 'b' are matrices and 'a*b' returns a proxy object, > as a numerical library would do. In other languages you could make that claim > about 'var x = a*b', but in C++ it needs to be qualified, in some contexts the type > is correct for its use, in others it's undefined behavior. > Actually, you /do/ know it is the correct type for its use in /that/ line. If "a * b" returns a proxy, then "x" should be that proxy - "auto x" means you have the correct type. Whether you use that variable correctly later remains to be seen in the rest of the code. Code cannot be fully understood line by line, it also cannot be considered fully correct line by line.
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-20 07:10 -0800 |
| Message-ID | <102bb20b-53d4-4aab-a0fd-d62778b21a3an@googlegroups.com> |
| In reply to | #88127 |
On Tuesday, December 20, 2022 at 7:46:54 AM UTC-5, David Brown wrote: > On 19/12/2022 16:10, daniel...@gmail.com wrote: > > On Monday, December 19, 2022 at 9:40:14 AM UTC-5, David Brown wrote: > >> Why do you care what type it is? Surely the > >> important thing about "x" is that it is the result of multiplying "a" > >> and "b", not its type. If you use "auto", you know that type is correct > >> for its use > > > > Actually you don't if 'a' and 'b' are matrices and 'a*b' returns a proxy object, > > as a numerical library would do. In other languages you could make that claim > > about 'var x = a*b', but in C++ it needs to be qualified, in some contexts the type > > is correct for its use, in others it's undefined behavior. > > > > Actually, you /do/ know it is the correct type for its use in /that/ > line. If "a * b" returns a proxy, then "x" should be that proxy - "auto > x" means you have the correct type. > The fact that you believe that makes the point that C++ coders should be especially judicious in the use of auto. Authors of the numerical libraries don't believe that, they write posts to StackOverflow asking if there are ways to avoid the "auto value = copy of proxy" problem (there aren't), because it's causing bugs in client code. Or they contribute to a proposal 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. But you believe that. A team lead could be forgiven for being reluctant to have you on a project where the Eigen, Armadillo or blaze libraries were being used. Daniel
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-20 18:39 +0100 |
| Message-ID | <tnss17$o8sf$2@dont-email.me> |
| In reply to | #88138 |
On 20/12/2022 16:10, daniel...@gmail.com wrote: > On Tuesday, December 20, 2022 at 7:46:54 AM UTC-5, David Brown wrote: >> On 19/12/2022 16:10, daniel...@gmail.com wrote: >>> On Monday, December 19, 2022 at 9:40:14 AM UTC-5, David Brown wrote: > >>>> Why do you care what type it is? Surely the >>>> important thing about "x" is that it is the result of multiplying "a" >>>> and "b", not its type. If you use "auto", you know that type is correct >>>> for its use >>> >>> Actually you don't if 'a' and 'b' are matrices and 'a*b' returns a proxy object, >>> as a numerical library would do. In other languages you could make that claim >>> about 'var x = a*b', but in C++ it needs to be qualified, in some contexts the type >>> is correct for its use, in others it's undefined behavior. >>> >> >> Actually, you /do/ know it is the correct type for its use in /that/ >> line. If "a * b" returns a proxy, then "x" should be that proxy - "auto >> x" means you have the correct type. >> > The fact that you believe that makes the point that C++ coders should > be especially judicious in the use of auto. Authors of the numerical libraries > don't believe that, they write posts to StackOverflow asking if there are > ways to avoid the "auto value = copy of proxy" problem (there aren't), > because it's causing bugs in client code. Or they contribute to a proposal > 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. > > But you believe that. A team lead could be forgiven for being reluctant to > have you on a project where the Eigen, Armadillo or blaze libraries were > being used. > I haven't used any of these, so I would want to see how they are generally used before trying to write code with them. As I said, "auto" gives you the correct type because it is the type returned by the multiplication - that does not mean it is the type you really wanted for the code, or that following code uses it correctly. Surely if making a copy of a proxy is inappropriate, the proxy class should disallow copying? And isn't the idea of these kind of expression template libraries that you get proxies, and can manipulate them as though they were "real" objects, and only do the actual calculations at the end?
[toc] | [prev] | [next] | [standalone]
| From | "daniel...@gmail.com" <danielaparker@gmail.com> |
|---|---|
| Date | 2022-12-20 11:20 -0800 |
| Message-ID | <3696ec6f-672c-4d33-a494-2b3891b3fe17n@googlegroups.com> |
| In reply to | #88148 |
On Tuesday, December 20, 2022 at 12:40:06 PM UTC-5, David Brown wrote: > "auto" gives you the correct type because it is the type returned by the > multiplication - that does not mean it is the type you really wanted for > the code, or that following code uses it correctly. > ??? Within intermediate calculations (A + B + C) * D yes, but the final result is intended to decay to a non-proxy type, the proxy is intended to be hidden from the user. Much as a std::vector<bool>::reference proxy is intended to decay to a bool. auto defeats that. > Surely if making a copy of a proxy is inappropriate, the proxy class > should disallow copying? Because of RVO, it's hard to defeat `auto x = foo()`. My understanding is that the committee has discussed the 2017 paper previously linked to, and concluded that there is no solution within current C++. It would require a language change. In the meantime, it would appear that the use of auto should be approached with some caution in C++, more so than with var in other languages. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 16:03 +0000 |
| Message-ID | <tnq1vj$gaa$1@gioia.aioe.org> |
| In reply to | #88047 |
David Brown <david.brown@hesbynett.no> wrote:
>> Incidentally, naming those variables more clearly could also help
>> understanding better that line of code. For example, if the variables
>> were named "row_index" and "table_width", suddenly that line becomes
>> extraordinarily clearer than if they are just "a" and "b".
>
> I don't care about the clarity of the line. I care about the clarity of
> the /code/. Do you understand the difference?
>
> const auto b = table.width();
> for (auto a = 0; a < table.row_count(); a++) {
> auto x = a * b;
> ...
>
> The code in question is /clearer/ than using "row_index" and
> "table_width" would be, because it is simple and quick to parse
> mentally, and all the relevant information about "a" and "b" is
> immediately available.
What is clear here is that you are just arguing for the sake of arguing.
I don't think even you believe what you are writing anymore. You are
just opposing on principle and nothing else.
It's absolutely incredible that someone could seriously claim that
"a" and "b" are clearer names than "row_index" and "table_width".
I will give you the benefit of the doubt and not make any claims about
your intelligence, and instead just assume that you are just arguing
for the sake of argument. That's the better alternative.
[toc] | [prev] | [next] | [standalone]
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web