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 1 of 17 [1] 2 3 … 17 Next page →
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-08 12:31 +0000 |
| Subject | Overuse of 'auto' |
| Message-ID | <tmslfi$h09$1@gioia.aioe.org> |
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'...
[toc] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-12-08 15:25 +0100 |
| Message-ID | <jveaeqFfmu6U1@mid.individual.net> |
| In reply to | #87753 |
On 2022-12-08 at 13:31, 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); > Of course "overuse" is always bad, by definition. :-) But here the problem could also be the use of names such as foobar and someFunction. Why do they not tell what is happening?! When I see code like auto iter = container.begin(); I know that auto means "some kind of iterator", and don't really care about exactly which one it is. And if it is auto size = user_name.size(); it doesn't help a bit if auto is replaced by size_type, because what type is size_type **really**?! Perhaps if we see auto as an automatic typedef, we can hate it less?
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-08 15:48 +0000 |
| Message-ID | <tmt0vo$1hg1$1@gioia.aioe.org> |
| In reply to | #87753 |
On Thu, 8 Dec 2022 12:31:48 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >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"). To be fair you could use the same argument about templating. Many times I've seem a template function thats only ever used for 2 different types.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-12-08 19:29 +0000 |
| Message-ID | <172ee82d26cb4cc6$250$3546400$baa1eca3@news.newsdemon.com> |
| In reply to | #87759 |
On Thu, 08 Dec 2022 15:48:08 +0000, Muttley wrote: > On Thu, 8 Dec 2022 12:31:48 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >>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"). > > To be fair you could use the same argument about templating. Many times > I've seem a template function thats only ever used for 2 different > types. You should use a template if there are N types where N > 1, and guess what? 2 > 1. Why? Because code duplication is bad even if there is only one duplicate. You seem to be fractally wrong about most things. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-12-09 15:52 +0000 |
| Message-ID | <tmvljc$i6p$1@gioia.aioe.org> |
| In reply to | #87761 |
On Thu, 08 Dec 2022 19:29:52 +0000 Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >On Thu, 08 Dec 2022 15:48:08 +0000, Muttley wrote: > >> On Thu, 8 Dec 2022 12:31:48 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >>>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"). >> >> To be fair you could use the same argument about templating. Many times >> I've seem a template function thats only ever used for 2 different >> types. > >You should use a template if there are N types where N > 1, and guess >what? 2 > 1. Why? Because code duplication is bad even if there is only >one duplicate. You seem to be fractally wrong about most things. As usual you're confusing your opinion with fact.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-09 12:52 +0000 |
| Message-ID | <tmvb2m$1jri$1@gioia.aioe.org> |
| In reply to | #87759 |
Muttley@dastardlyhq.com wrote: > To be fair you could use the same argument about templating. Many times > I've seem a template function thats only ever used for 2 different types. Incidentally, one of the things I have learned to hate when reading other people's code (and which I could write an entire book about), is useless function overloading that serves no purpose. Way too often do you see code out there that overloads a function for different types even though there's literally no technical reason nor any sort of advantage in overloading it. It's done purely as a naming thing, and that's it. There's no technical reason or purpose behind it. You wouldn't believe, just like with the over-use of 'auto', how frustratingly difficult it can be to read code that uses too much function overloading at the expense of code readability and understandability. That's because excessive overloading tends to mean that the function name doesn't tell very explicitly what it's doing, because the same name is being used for a myriad of different types. Not only can this cause ambiguity from the compiler's perspective, but it very much can cause ambiguity for the person who is reading the code. My personal opinion is: In the vast, vast majority of cases write distinct function names for each distinct function (and the function name should be quite clear about what it's doing, and how what it's doing is different from the other functions that you would have overloaded otherwise), and if you really, really need to overload the function for some reason (eg. because the function is being used in templated code), implement the overloads separately and make them call the distinctively-named versions. And always use the distinctively-named versions in your code unless there's an actual good reason to use the overloaded versions. Readability is more important than convenience.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-12-09 05:03 -0800 |
| Message-ID | <025ddabb-0efa-4a7c-a374-ded702197e7an@googlegroups.com> |
| In reply to | #87774 |
On Friday, December 9, 2022 at 2:52:59 PM UTC+2, Juha Nieminen wrote: > Mut...@dastardlyhq.com wrote: > > To be fair you could use the same argument about templating. Many times > > I've seem a template function thats only ever used for 2 different types. > Incidentally, one of the things I have learned to hate when reading other > people's code (and which I could write an entire book about), is useless > function overloading that serves no purpose. > > Way too often do you see code out there that overloads a function for > different types even though there's literally no technical reason nor > any sort of advantage in overloading it. It's done purely as a naming > thing, and that's it. There's no technical reason or purpose behind it. > > You wouldn't believe, just like with the over-use of 'auto', how > frustratingly difficult it can be to read code that uses too much > function overloading at the expense of code readability and > understandability. That's because excessive overloading tends to > mean that the function name doesn't tell very explicitly what > it's doing, because the same name is being used for a myriad of > different types. Not only can this cause ambiguity from the > compiler's perspective, but it very much can cause ambiguity for the > person who is reading the code. > > My personal opinion is: In the vast, vast majority of cases write > distinct function names for each distinct function (and the function > name should be quite clear about what it's doing, and how what > it's doing is different from the other functions that you would > have overloaded otherwise), and if you really, really need to > overload the function for some reason (eg. because the function is > being used in templated code), implement the overloads separately > and make them call the distinctively-named versions. And always use > the distinctively-named versions in your code unless there's an actual > good reason to use the overloaded versions. Readability is more important > than convenience. You are maturing. Few more years and you'll start to agree with your famous former compatriot. "C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.". https://lwn.net/Articles/249460/
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-09 14:15 +0000 |
| Message-ID | <oqHkL.5023$MVg8.633@fx12.iad> |
| In reply to | #87777 |
Michael S <already5chosen@yahoo.com> writes: >On Friday, December 9, 2022 at 2:52:59 PM UTC+2, Juha Nieminen wrote: >> Mut...@dastardlyhq.com wrote: >> > To be fair you could use the same argument about templating. Many times >> > I've seem a template function thats only ever used for 2 different types. >> Incidentally, one of the things I have learned to hate when reading other >> people's code (and which I could write an entire book about), is useless >> function overloading that serves no purpose. >> >> Way too often do you see code out there that overloads a function for >> different types even though there's literally no technical reason nor >> any sort of advantage in overloading it. It's done purely as a naming >> thing, and that's it. There's no technical reason or purpose behind it. >> >> You wouldn't believe, just like with the over-use of 'auto', how >> frustratingly difficult it can be to read code that uses too much >> function overloading at the expense of code readability and >> understandability. That's because excessive overloading tends to >> mean that the function name doesn't tell very explicitly what >> it's doing, because the same name is being used for a myriad of >> different types. Not only can this cause ambiguity from the >> compiler's perspective, but it very much can cause ambiguity for the >> person who is reading the code. >> >> My personal opinion is: In the vast, vast majority of cases write >> distinct function names for each distinct function (and the function >> name should be quite clear about what it's doing, and how what >> it's doing is different from the other functions that you would >> have overloaded otherwise), and if you really, really need to >> overload the function for some reason (eg. because the function is >> being used in templated code), implement the overloads separately >> and make them call the distinctively-named versions. And always use >> the distinctively-named versions in your code unless there's an actual >> good reason to use the overloaded versions. Readability is more important >> than convenience. > >You are maturing. >Few more years and you'll start to agree with your famous former compatriot. > >"C++ is a horrible language. It's made more horrible by the fact that a lot >of substandard programmers use it, to the point where it's much much >easier to generate total and utter crap with it. Quite frankly, even if >the choice of C were to do *nothing* but keep the C++ programmers out, >that in itself would be a huge reason to use C.". Sturgeon's Law applies.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-12 06:59 +0000 |
| Message-ID | <tn6jgq$d6c$1@gioia.aioe.org> |
| In reply to | #87777 |
Michael S <already5chosen@yahoo.com> wrote: > You are maturing. > Few more years and you'll start to agree with your famous former compatriot. > > "C++ is a horrible language. It's made more horrible by the fact that a lot > of substandard programmers use it, to the point where it's much much > easier to generate total and utter crap with it. Quite frankly, even if > the choice of C were to do *nothing* but keep the C++ programmers out, > that in itself would be a huge reason to use C.". > > https://lwn.net/Articles/249460/ I hope I never become that retarded.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2022-12-17 16:53 +0000 |
| Message-ID | <slrntprsvj.h7h.grahn+nntp@frailea.sa.invalid> |
| In reply to | #87774 |
On Fri, 2022-12-09, Juha Nieminen wrote: > Muttley@dastardlyhq.com wrote: >> To be fair you could use the same argument about templating. Many times >> I've seem a template function thats only ever used for 2 different types. > > Incidentally, one of the things I have learned to hate when reading other > people's code (and which I could write an entire book about), is useless > function overloading that serves no purpose. > > Way too often do you see code out there that overloads a function for > different types even though there's literally no technical reason nor > any sort of advantage in overloading it. It's done purely as a naming > thing, and that's it. There's no technical reason or purpose behind it. > > You wouldn't believe, just like with the over-use of 'auto', how > frustratingly difficult it can be to read code that uses too much > function overloading at the expense of code readability and > understandability. That's because excessive overloading tends to > mean that the function name doesn't tell very explicitly what > it's doing, because the same name is being used for a myriad of > different types. Not only can this cause ambiguity from the > compiler's perspective, but it very much can cause ambiguity for the > person who is reading the code. > > My personal opinion is: In the vast, vast majority of cases write > distinct function names for each distinct function (and the function > name should be quite clear about what it's doing, and how what > it's doing is different from the other functions that you would > have overloaded otherwise), and if you really, really need to > overload the function for some reason (eg. because the function is > being used in templated code), implement the overloads separately > and make them call the distinctively-named versions. And always use > the distinctively-named versions in your code unless there's an actual > good reason to use the overloaded versions. Readability is more important > than convenience. There seems to be at least as many opinions on style as there are C++ programmers. Your first post in the thread could have been written by me (except thankfully people around me haven't read too much Herb Sutter, and don't overuse auto). But for function names my taste is the opposite. The parameter list is part of the function signature, and I take that into account when choosing a name. I also like short names without redundant information. So there's a lot of "find", "size", "empty" and so on. If I have problems coming up with a name like that, the first thing I do is check if I should review my set of types. To me this isn't a maintenance problem: it's obvious at the call site which one I mean. If it's not, then I haven't understood the calling code well enough to have a reason to follow the call. Tags lookup in Emacs doesn't like overloading, though[0]. And yesterday learned that, surprisingly, my coworkers' fancy IDEs don't like it either. Unfortunate ... but it's not enough to make me reconsider. /Jorgen [0] Or maybe I haven't learned how to use it properly. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 07:32 +0000 |
| Message-ID | <tnp425$bna$1@gioia.aioe.org> |
| In reply to | #87993 |
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > But for function names my taste is the opposite. The parameter list > is part of the function signature, and I take that into account when > choosing a name. I also like short names without redundant > information. So there's a lot of "find", "size", "empty" and so on. > If I have problems coming up with a name like that, the first thing I > do is check if I should review my set of types. Sure, names should not contain *redundant* information. Ie. names should not contain English words that do not add information to the name that's already conveyed by the other words in the name (ie. there's no need to state the same thing twice, even if you use two different words to express the thing). Also words that may not repeat what other words in the name are already saying, but which do not add any information to the name can be avoided. However, variable/function/type names should still use as many words as necessary to clearly express and disambiguate what it's doing or what its role is. As an example, "convert()" doesn't contain enough information to tell me what that function is doing. Convert what? Into what? Such a function name should tell directly what it's converting, and into what, so that it becomes clear from that name alone. If you require a more generic name like that for the purposes of overloading (eg. because that overloaded function is being used in templated code), IMO it's *still* preferable to create uniquely-named functions that disambiguate what they are doing, and then make the overloaded functions call those. And in code that does not need the overloading the uniquely-named versions should be called. This is because it makes the code easier to read and understand. > To me this isn't a maintenance problem: it's obvious at the call site > which one I mean. If it's not, then I haven't understood the calling > code well enough to have a reason to follow the call. You should not be writing code for yourself. You should be writing it for others. Obviously *you* understand what the code is doing because you are writing it. You already know the intent, and you are just implementing that intent. However, a third-party reader doesn't know the intent of the code beforehand, and thus the direction is reversed: The third-party reader needs to decipher the intent from the code. And that "third-party reader" may well be you yourself, years later, long after you have forgotten the details of the code. So in that way you are also writing it for your (future) self.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-08 07:59 -0800 |
| Message-ID | <69e27519-337d-4891-9af3-0cccced7b6abn@googlegroups.com> |
| In reply to | #87753 |
On Thursday, 8 December 2022 at 14:32:04 UTC+2, 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'...
Yes but it is tedious. Some types are *LONG*, especially what templates
can return. Some are not possible to express. Like in functional
programming:
auto ret_fun() { return [](int x) { return x; }; }
auto& int_returner = ret_fun();
Should I wrap the return value into std::function<int(int)> to have it possible
to express its type? Is that free or brings some overhead? What if there
is combo of templates that accept as arguments and return lambdas?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-09 12:56 +0000 |
| Message-ID | <tmvb9r$1n54$1@gioia.aioe.org> |
| In reply to | #87760 |
Öö 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. What exactly are you saving by shortening names (especially if shortening them to something that tells absolutely nothing about the actual type)? Disk space? Or are you really in such a hurty that you can't spend a few seconds typing the longer name? > Some are not possible to express. Like in functional > programming: C++ lambdas are special in that the standard explicitly states that they don't have a named type and that the only way to handle them is with 'auto'. In this case there's a good *technical* reason to use 'auto'. It's not merely used for convenience or avoiding writing a couple of extra characters.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-12-09 07:57 -0800 |
| Message-ID | <fb9b4220-1edc-43bf-90b7-8cb2a7a8675bn@googlegroups.com> |
| In reply to | #87775 |
On Friday, 9 December 2022 at 14:56:48 UTC+2, Juha Nieminen wrote: > Öö Tiib <oot...@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. > > What exactly are you saving by shortening names (especially if shortening > them to something that tells absolutely nothing about the actual type)? > Disk space? Or are you really in such a hurty that you can't spend a few > seconds typing the longer name? I was not talking about "name" but "type" with number of template arguments some of what are also templates and nested.The simpler cases are almost tolerable but real types to deal with get hairy fast: std::map<std::string_view, std::function<int(void)>>::insert_return_type That when one should know fully well what map::insert returns pair of its iterator and bool. > > Some are not possible to express. Like in functional > > programming: > C++ lambdas are special in that the standard explicitly states that > they don't have a named type and that the only way to handle them is > with 'auto'. > > In this case there's a good *technical* reason to use 'auto'. It's > not merely used for convenience or avoiding writing a couple of extra > characters. OK
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-09 17:44 +0000 |
| Message-ID | <87tu2479qc.fsf@bsb.me.uk> |
| 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. As usual, such rules oversimplify the issues. Sometime clarity can actually come from brevity. 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>) ... Where in your spectrum of clarity vs. brevity does this sort of use come? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> |
|---|---|
| Date | 2022-12-09 21:01 +0100 |
| Message-ID | <20221209210141.31afa7ff@blackbird.dehmel-lan.de> |
| In reply to | #87781 |
On Fri, 09 Dec 2022 17:44:27 +0000 Ben Bacarisse <ben.usenet@bsb.me.uk> 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. > > As usual, such rules oversimplify the issues. Sometime clarity can > actually come from brevity. > > 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>) ... > > Where in your spectrum of clarity vs. brevity does this sort of use > come? I'd say it's on the lowest end of the spectrum. As soon as people start decorating their "auto" with things like "const", "*" or "&" it _always_ is. Either the type is self-explanatory or irrelevant, in which case plain "auto" will do, or it isn't, in which case "auto" is conceptually wrong. Decorating "auto" like that is just a pathetic attempt at hiding this simple fact. Andreas
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-09 20:47 +0000 |
| Message-ID | <87leng7196.fsf@bsb.me.uk> |
| In reply to | #87783 |
Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> writes: > On Fri, 09 Dec 2022 17:44:27 +0000 > Ben Bacarisse <ben.usenet@bsb.me.uk> 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. >> >> As usual, such rules oversimplify the issues. Sometime clarity can >> actually come from brevity. >> >> 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>) ... >> >> Where in your spectrum of clarity vs. brevity does this sort of use >> come? > > I'd say it's on the lowest end of the spectrum. As soon as people start > decorating their "auto" with things like "const", "*" or "&" it > _always_ is. Either the type is self-explanatory or irrelevant, in > which case plain "auto" will do, or it isn't, in which case "auto" is > conceptually wrong. Decorating "auto" like that is just a pathetic > attempt at hiding this simple fact. If I read you correctly, you think that adding const means the auto is almost always wrong. Is that your position? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> |
|---|---|
| Date | 2022-12-10 14:48 +0100 |
| Message-ID | <20221210144835.5ad5aafa@blackbird.dehmel-lan.de> |
| In reply to | #87785 |
On Fri, 09 Dec 2022 20:47:33 +0000 Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> writes: > > > On Fri, 09 Dec 2022 17:44:27 +0000 > > Ben Bacarisse <ben.usenet@bsb.me.uk> 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. > >> > >> As usual, such rules oversimplify the issues. Sometime clarity can > >> actually come from brevity. > >> > >> 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>) ... > >> > >> Where in your spectrum of clarity vs. brevity does this sort of use > >> come? > > > > I'd say it's on the lowest end of the spectrum. As soon as people > > start decorating their "auto" with things like "const", "*" or "&" > > it _always_ is. Either the type is self-explanatory or irrelevant, > > in which case plain "auto" will do, or it isn't, in which case > > "auto" is conceptually wrong. Decorating "auto" like that is just a > > pathetic attempt at hiding this simple fact. > > If I read you correctly, you think that adding const means the auto is > almost always wrong. Is that your position? Like I wrote, my position is that adding _any_of_ "const", "*" or "&" to auto is doing it wrong. It's just trying to hide the fact that you actually want a specific type but are too lazy to write it down. And as a general aside, not just relating to "auto", in a language like C++ where you usually have a long maintenance window, the pains of the author are insignificant compared to the pains of the maintainer(s). Andreas
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-12-10 21:52 +0000 |
| Message-ID | <87r0x753ke.fsf@bsb.me.uk> |
| In reply to | #87797 |
Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> writes: > On Fri, 09 Dec 2022 20:47:33 +0000 > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > >> Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> writes: >> >> > On Fri, 09 Dec 2022 17:44:27 +0000 >> > Ben Bacarisse <ben.usenet@bsb.me.uk> 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. >> >> >> >> As usual, such rules oversimplify the issues. Sometime clarity can >> >> actually come from brevity. >> >> >> >> 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>) ... >> >> >> >> Where in your spectrum of clarity vs. brevity does this sort of use >> >> come? >> > >> > I'd say it's on the lowest end of the spectrum. As soon as people >> > start decorating their "auto" with things like "const", "*" or "&" >> > it _always_ is. Either the type is self-explanatory or irrelevant, >> > in which case plain "auto" will do, or it isn't, in which case >> > "auto" is conceptually wrong. Decorating "auto" like that is just a >> > pathetic attempt at hiding this simple fact. >> >> If I read you correctly, you think that adding const means the auto is >> almost always wrong. Is that your position? > > Like I wrote, my position is that adding _any_of_ "const", "*" or "&" > to auto is doing it wrong. It's just trying to hide the fact that you > actually want a specific type but are too lazy to write it down. That strikes me as a very strange opinion, but is there any point in us (you and I) examining it? In my experience, investigating that sort of opinion, expressed in that style, is rarely fruitful. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-12-11 00:29 +0100 |
| Message-ID | <tn34oo$1ocgl$1@dont-email.me> |
| In reply to | #87804 |
On 10 Dec 2022 22:52, Ben Bacarisse wrote:
> Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> writes:
>
>> On Fri, 09 Dec 2022 20:47:33 +0000
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> writes:
>>>
>>>> On Fri, 09 Dec 2022 17:44:27 +0000
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> 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.
>>>>>
>>>>> As usual, such rules oversimplify the issues. Sometime clarity can
>>>>> actually come from brevity.
>>>>>
>>>>> 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>) ...
>>>>>
>>>>> Where in your spectrum of clarity vs. brevity does this sort of use
>>>>> come?
>>>>
>>>> I'd say it's on the lowest end of the spectrum. As soon as people
>>>> start decorating their "auto" with things like "const", "*" or "&"
>>>> it _always_ is. Either the type is self-explanatory or irrelevant,
>>>> in which case plain "auto" will do, or it isn't, in which case
>>>> "auto" is conceptually wrong. Decorating "auto" like that is just a
>>>> pathetic attempt at hiding this simple fact.
>>>
>>> If I read you correctly, you think that adding const means the auto is
>>> almost always wrong. Is that your position?
>>
>> Like I wrote, my position is that adding _any_of_ "const", "*" or "&"
>> to auto is doing it wrong. It's just trying to hide the fact that you
>> actually want a specific type but are too lazy to write it down.
>
> That strikes me as a very strange opinion, but is there any point in us
> (you and I) examining it? In my experience, investigating that sort of
> opinion, expressed in that style, is rarely fruitful.
Example.
class Holder
{
using Variant = variant<
// possible types here
>;
Variant m_variant;
public:
template< class Type >
Holder( in_<Type> e ): m_variant( e ) {}
template< class Type >
auto holds() const
-> bool
{
// TODO: optimize via compile time decisions (type lists).
const auto is_specified_type = []( const auto& e ) -> bool
{
return are_derived_and_base_< Unref_<decltype( e )>,
Type >;
};
return visit( is_specified_type, m_variant );
}
[toc] | [prev] | [next] | [standalone]
Page 1 of 17 [1] 2 3 … 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web