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 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
| From | Andreas Dehmel <blackhole.8.zarquon42@spamgourmet.com> |
|---|---|
| Date | 2022-12-11 14:37 +0100 |
| Message-ID | <20221211143711.742624f0@blackbird.dehmel-lan.de> |
| In reply to | #87805 |
On Sun, 11 Dec 2022 00:29:26 +0100
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote:
> 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 );
> }
>
>
Not sure whether you're arguing for or against, but
auto function(...) -> bool
can only be a bad joke and is_specified_type() is basically a bog
standard template function that thinks all the cool kids are using auto.
Andreas
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-12-12 09:35 +0100 |
| Message-ID | <tn6p4k$26hog$1@dont-email.me> |
| In reply to | #87810 |
On 11 Dec 2022 14:37, Andreas Dehmel wrote:
> On Sun, 11 Dec 2022 00:29:26 +0100
> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote:
>
>> 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 );
>> }
>
> Not sure whether you're arguing for or against, but
> auto function(...) -> bool
> can only be a bad joke and is_specified_type() is basically a bog
> standard template function that thinks all the cool kids are using auto.
It's good that you feel free to express your opinions in this group.
- Alf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-11 16:42 +0100 |
| Message-ID | <tn4tq2$1vab1$3@dont-email.me> |
| In reply to | #87797 |
On 10/12/2022 14:48, Andreas Dehmel wrote: > 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. > When someone writes "const auto &elem", they are saying the details of the actual type are not vital to the working of the code - but it /is/ important that the variable is "const" and a reference, giving efficient read-only access. It is emphasising and being explicit about the important aspects while neatly omitting unimportant (for the code in question) details.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-12-09 13:07 -0800 |
| Message-ID | <86leng476z.fsf@linuxsc.com> |
| 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: >> >>> [...] 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. The assertion that "auto" is conceptually wrong is an opinion, not a fact.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-12 07:14 +0000 |
| Message-ID | <tn6kc9$o2k$1@gioia.aioe.org> |
| In reply to | #87781 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> It's usually more enlightening to give what you consider good and bad
> examples as well some examples on the boundary. For example, I rarely
> want to know more about the type when I see
>
> for (const auto &elem : <something>) ...
I find it quite strange that you aren't interested in what that element
type is. When you know nothing about the type, you have no way of
knowing what to expect in the subsequent lines of code. Looking at
that line alone it may be completely unclear what it's actually doing
(depending on what that <something> is).
Compare it to, say:
for (const std::string& elem: <something>)
Aha! Now we know a lot more about what <something> is, and what to
expect in subsequent lines of code. Just that one little change is
giving us a lot more information and clarity about what's happening here.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-12 08:54 +0100 |
| Message-ID | <tn6mo8$26d8p$1@dont-email.me> |
| In reply to | #87819 |
On 12/12/2022 08:14, Juha Nieminen wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> It's usually more enlightening to give what you consider good and bad
>> examples as well some examples on the boundary. For example, I rarely
>> want to know more about the type when I see
>>
>> for (const auto &elem : <something>) ...
>
> I find it quite strange that you aren't interested in what that element
> type is. When you know nothing about the type, you have no way of
> knowing what to expect in the subsequent lines of code. Looking at
> that line alone it may be completely unclear what it's actually doing
> (depending on what that <something> is).
>
I find it strange that you expect to understand code line by line,
rather than looking at the context. This is especially true given that
full types in C++ can regularly take more than a single line to write out.
When I use "auto", it is because the details of the type don't matter
significantly, or they are clear from the context, or that they are too
convoluted to be convenient to write out manually, or that the code is
intended to be somewhat general. I think a combination of the first two
is the most common.
> Compare it to, say:
>
> for (const std::string& elem: <something>)
>
> Aha! Now we know a lot more about what <something> is, and what to
> expect in subsequent lines of code. Just that one little change is
> giving us a lot more information and clarity about what's happening here.
Compare it to :
void foo(std::vector<std::string> somethings) {
for (const auto &elem : somethings) ...
Why bother re-writing std::string inside the for loop? It doesn't make
the code any clearer or safer - it is unnecessary repetition.
(Programmers should have KISS tattooed on the inside of one eyelid, and
DRY tattooed on the inside of the other.) The types are clear as day.
And if they are changed - maybe "foo" gets changed to wide strings - the
rest of the code is unchanged with "auto". But if you have manually
written out the full type, you now have to remember to make changes in
more places or you've got highly unexpected conversions lying around.
/Overuse/ of auto is, of course, a bad thing - overuse of anything is
bad, by the definition of the word. And sometimes there are better
alternatives, such as "using" to make a local typename that is more
convenient, or concepts as "constrained auto". But very often, "auto"
is simple, convenient, improves clarity and reduces the risk of errors.
In such cases it is a very good thing.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-12 11:31 +0000 |
| Message-ID | <tn73fa$1i5e$1@gioia.aioe.org> |
| In reply to | #87820 |
David Brown <david.brown@hesbynett.no> wrote:
> I find it strange that you expect to understand code line by line,
> rather than looking at the context.
I don't find it strange at all. The clearer the code is, the better.
If you can understand what a line of code is doing without having
to look at the surrounding code, all the better. (Sometimes this is
just not possible, of course, but if with a simple change you can
make it so, why not?)
> This is especially true given that
> full types in C++ can regularly take more than a single line to write out.
There we go again with the brevity argument.
My disdain for overt brevity has not appeared out of the blue. It's the
consequence of years of having to have read tens of thousands of lines
of code written by other people.
Length does not matter. Clarity does.
> When I use "auto", it is because the details of the type don't matter
> significantly, or they are clear from the context, or that they are too
> convoluted to be convenient to write out manually, or that the code is
> intended to be somewhat general. I think a combination of the first two
> is the most common.
*Maybe* if what 'auto' expands to is *extremely* clear to see from the
code, then *perhaps* it's acceptable. However, my point is that 'auto'
is being *overused* a lot. In other words, in many situations where
it's *not* clear at all what it's expanding to (often requiring going
to an entirely different file to see what it actually is. IDEs help
with this, but IMO code should be readable without the help of any
IDEs.)
>> Compare it to, say:
>>
>> for (const std::string& elem: <something>)
>>
>> Aha! Now we know a lot more about what <something> is, and what to
>> expect in subsequent lines of code. Just that one little change is
>> giving us a lot more information and clarity about what's happening here.
>
> Compare it to :
>
> void foo(std::vector<std::string> somethings) {
>
> for (const auto &elem : somethings) ...
Then, in the future, as you further develop the code, you add a couple
dozen lines before that loop. Will you then change that 'auto' to the
actual type? Unlikely.
> Why bother re-writing std::string inside the for loop? It doesn't make
> the code any clearer or safer - it is unnecessary repetition.
It's not unnecessary repetition if it makes the code easier to understand.
You write the same words in your English prose again and again and again.
You don't see that as a problem. Why do you find it a problem in code?
> (Programmers should have KISS tattooed on the inside of one eyelid, and
> DRY tattooed on the inside of the other.)
No, because if you keep it stupid, then your code will be stupid, and
nobody will understand it.
Keep your code smart, not stupid.
> And if they are changed - maybe "foo" gets changed to wide strings - the
> rest of the code is unchanged with "auto". But if you have manually
> written out the full type, you now have to remember to make changes in
> more places or you've got highly unexpected conversions lying around.
Conversely, if you accidentally write the wrong type when refactoring
code, subsequent 'auto' keywords may hide your mistake, while explicit
types could have caught it immediately.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-12 16:11 +0100 |
| Message-ID | <tn7gba$28ej3$1@dont-email.me> |
| In reply to | #87826 |
On 12/12/2022 12:31, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> I find it strange that you expect to understand code line by line,
>> rather than looking at the context.
>
> I don't find it strange at all. The clearer the code is, the better.
> If you can understand what a line of code is doing without having
> to look at the surrounding code, all the better. (Sometimes this is
> just not possible, of course, but if with a simple change you can
> make it so, why not?)
>
We agree that clearer code is better, all other things being equal. I
think that's a given. But we might disagree on what makes code clearer.
I gave several reasons why using an explicit type does not necessarily
make code "better", or why it might not be a "simple change". But even
when the change is simple, it would not necessarily bring any benefits.
To understand what code is doing, you almost always have to look at the
context. It is good that you should not have to look too far (or not
have to look far too often), but restricting your gaze to a single line
is arbitrarily and unnecessarily small.
>> This is especially true given that
>> full types in C++ can regularly take more than a single line to write out.
>
> There we go again with the brevity argument.
If you can't see the wood for the trees, the code is unhelpfully
long-winded.
Programming languages are based on the idea of shorter and more
convenient ways of referring to things - they are easier to read, easier
to write, easier to get correct, and more flexible. Why do we write
functions, rather than manually expanding them inline in your code?
Brevity makes the higher level function clearer. Why do we write "using
namespace" clauses, or "using" for type names? They make code clearer -
when used appropriately.
Making names too short or otherwise compacting code too much makes it
hard to read and comprehend. Making it all too long and verbose makes
it hard to read and comprehend. Pick a suitable middle ground.
>
> My disdain for overt brevity has not appeared out of the blue. It's the
> consequence of years of having to have read tens of thousands of lines
> of code written by other people.
>
> Length does not matter. Clarity does.
If you think clarity increases with length, you haven't read enough
code. Tens of thousands of lines is not a lot.
The sweet spot is /always/ in the middle.
Let's take a different case. If I want an integer to store numbers in
the range of 15 decimal digits, I'll write :
int64_t x;
I won't write :
signed long long int x;
even though the later is more portable, more explicit, and avoids an
unnecessary non-portable requirement of the implementation having a type
of exactly 64 bits. I won't even bother with "int_fast64_t", or
"int_least64_t". Technically, "signed long long int" is a more precise
specification for my needs. "int64_t" is much clearer, however - partly
because it is shorter.
A general rule of thumb is that for a given task, code in a higher level
language will take fewer lines than in a lower level language, and will
be clearer and contain fewer mistakes. (Studies show that the error
rate per line of code is mostly independent of the programming language
or the style of coding.) On the other hand, lower level languages give
you more control and often higher efficiency. C++ lets you do both high
and low level coding in the same language.
>
>> When I use "auto", it is because the details of the type don't matter
>> significantly, or they are clear from the context, or that they are too
>> convoluted to be convenient to write out manually, or that the code is
>> intended to be somewhat general. I think a combination of the first two
>> is the most common.
>
> *Maybe* if what 'auto' expands to is *extremely* clear to see from the
> code, then *perhaps* it's acceptable. However, my point is that 'auto'
> is being *overused* a lot. In other words, in many situations where
> it's *not* clear at all what it's expanding to (often requiring going
> to an entirely different file to see what it actually is. IDEs help
> with this, but IMO code should be readable without the help of any
> IDEs.)
I agree that IDE's help make code faster and easier to read (and
especially to navigate, if you need to move around) but should not be
necessary to understand code.
And no one disagrees with you that "auto" can be misused.
>
>>> Compare it to, say:
>>>
>>> for (const std::string& elem: <something>)
>>>
>>> Aha! Now we know a lot more about what <something> is, and what to
>>> expect in subsequent lines of code. Just that one little change is
>>> giving us a lot more information and clarity about what's happening here.
>>
>> Compare it to :
>>
>> void foo(std::vector<std::string> somethings) {
>>
>> for (const auto &elem : somethings) ...
>
> Then, in the future, as you further develop the code, you add a couple
> dozen lines before that loop. Will you then change that 'auto' to the
> actual type? Unlikely.
>
Will you need to change it to keep it clear? Unlikely.
If these dozen lines mean it is no longer clear, is changing "auto" to
an explicit type the best solution? /Very/ unlikely - in such a
situation, re-factoring the code (such as moving the dozen lines into
their own function) is going to give far greater benefits.
>> Why bother re-writing std::string inside the for loop? It doesn't make
>> the code any clearer or safer - it is unnecessary repetition.
>
> It's not unnecessary repetition if it makes the code easier to understand.
>
But in code like my snippet, it doesn't make it easier to understand.
> You write the same words in your English prose again and again and again.
> You don't see that as a problem. Why do you find it a problem in code?
Of course it can be a problem in prose. It can make the prose tedious
and therefore harder to read.
>
>> (Programmers should have KISS tattooed on the inside of one eyelid, and
>> DRY tattooed on the inside of the other.)
>
> No, because if you keep it stupid, then your code will be stupid, and
> nobody will understand it.
>
> Keep your code smart, not stupid.
KISS means "Keep it simple, stupid" - not "Keep it stupid". "auto" is
useful when it is simpler than manually and explicitly giving the type.
>
>> And if they are changed - maybe "foo" gets changed to wide strings - the
>> rest of the code is unchanged with "auto". But if you have manually
>> written out the full type, you now have to remember to make changes in
>> more places or you've got highly unexpected conversions lying around.
>
> Conversely, if you accidentally write the wrong type when refactoring
> code, subsequent 'auto' keywords may hide your mistake, while explicit
> types could have caught it immediately.
Write something once, and your chances of getting it wrong are lower
than writing it multiple types. Explicit types might just as easily
give you a conversion and hide your mistake.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-12 15:59 +0000 |
| Message-ID | <tn7j4e$1fjd$1@gioia.aioe.org> |
| In reply to | #87829 |
David Brown <david.brown@hesbynett.no> wrote: >>> This is especially true given that >>> full types in C++ can regularly take more than a single line to write out. >> >> There we go again with the brevity argument. > > If you can't see the wood for the trees, the code is unhelpfully > long-winded. I don't think you understand. The driving principle in writing code should be "this makes it easier to understand", not "this makes it shorter". It's not about making the names longer for the sake of making them longer. It's about making them easier to understand. If that means writing longer names, then so be it. There's zero reason to avoid longer names, if that makes the code clearer for the reader who is reading the code for the first time. (Conversely, if a name is so long that it makes it harder to understand, then express it more concisely and clearly.) The problem is that the majority of programmers do not choose names based on how easy it makes the code to understand for third-parties. They choose the names based on personal preference, which in the vast, vast majority of cases means overtly short names. Most programmers prefer writing "ret" instead of "returnValue", "err" instead of "errorCode", "genRandVal" instead of "generateRandomValue". They do not think if that makes the code harder for someone else to read. (And in the majority of cases if you point this out, they will ferociously defend their practice, against all logic.) If 'std::map<std::string, std::string>' makes the code easier to understand than 'auto', then write the former. There's no need to save disk space. Shorter is not always better. >> Length does not matter. Clarity does. > > If you think clarity increases with length, you haven't read enough > code. Tens of thousands of lines is not a lot. I have read enough code to know that brevity does not increase clarity, but the opposite. > Let's take a different case. If I want an integer to store numbers in > the range of 15 decimal digits, I'll write : > > int64_t x; > > I won't write : > > signed long long int x; > > even though the later is more portable, more explicit, and avoids an > unnecessary non-portable requirement of the implementation having a type > of exactly 64 bits. You are now trying to argue from redundancy. 'signed' and 'int' are redundant there. They don't add information. There's no need to say the same thing multiple times. Also, those two lines are not equivalent. It's not *merely* about naming conventions in this example. There's a functional difference. >> Keep your code smart, not stupid. > > KISS means "Keep it simple, stupid" - not "Keep it stupid". I suppose you choose to insult your readers then, rather than the second S referring to the code itself. Either way, I'd rather code be readable and understandable than simple.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-12 17:17 +0000 |
| Message-ID | <pmJlL.135227$8_id.9746@fx09.iad> |
| In reply to | #87831 |
Juha Nieminen <nospam@thanks.invalid> writes: >David Brown <david.brown@hesbynett.no> wrote: >>>> This is especially true given that >>>> full types in C++ can regularly take more than a single line to write out. >>> >>> There we go again with the brevity argument. >> >> If you can't see the wood for the trees, the code is unhelpfully >> long-winded. > >I don't think you understand. > >The driving principle in writing code should be "this makes it easier to >understand", not "this makes it shorter". The two goals are not in conflict. >The problem is that the majority of programmers do not choose names based "Most"? got a cite? >on how easy it makes the code to understand for third-parties. They choose >the names based on personal preference, which in the vast, vast majority >of cases means overtly short names. Most programmers prefer writing "ret" >instead of "returnValue", "err" instead of "errorCode", "genRandVal" >instead of "generateRandomValue". "Most" programmers find uppercase characters in the identifier are a productivity hit (more difficult to type, for instance) and have no other redeeming value. I'll take 'rval' over "returnValue" every time. long seed = random(); is perfectly readable and self documenting.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2022-12-12 22:02 +0000 |
| Message-ID | <slrntpf97a.c06.ike@iceland.freeshell.org> |
| In reply to | #87833 |
On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote: > long seed = random(); is perfectly readable and self documenting. The word choice is a bit unconventional. A seed is most often used as an initial input to a random number generator, not as the result of it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-12 22:41 +0000 |
| Message-ID | <U6OlL.14560$t5W7.9466@fx13.iad> |
| In reply to | #87837 |
Ike Naar <ike@sdf.org> writes: >On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote: >> long seed = random(); is perfectly readable and self documenting. > >The word choice is a bit unconventional. >A seed is most often used as an initial input to >a random number generator, not as the result of it. It's common to seed a PRNG with a random number. Preferably a true random number. It wasn't uncommon in the early days of unix games to seed the PRNG with the current time in seconds since the Epoch.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-12-12 16:00 -0800 |
| Message-ID | <87k02wtbp9.fsf@nosuchdomain.example.com> |
| In reply to | #87838 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Ike Naar <ike@sdf.org> writes:
>>On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> long seed = random(); is perfectly readable and self documenting.
>>
>>The word choice is a bit unconventional.
>>A seed is most often used as an initial input to
>>a random number generator, not as the result of it.
>
> It's common to seed a PRNG with a random number. Preferably
> a true random number.
If you can get a "true random number", you don't need a PRNG
(unless your source of true random numbers is slow or otherwise
resource-intensive). But it's rare to be able to get true random
numbers in the first place.
> It wasn't uncommon in the early days of unix games to seed
> the PRNG with the current time in seconds since the Epoch.
Which is hardly random.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-12-13 02:48 -0500 |
| Message-ID | <tn9aob$2be07$1@dont-email.me> |
| In reply to | #87839 |
On 12/12/22 19:00, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: ... >> It's common to seed a PRNG with a random number. Preferably >> a true random number. > > If you can get a "true random number", you don't need a PRNG > (unless your source of true random numbers is slow or otherwise > resource-intensive). It's my understanding that there are indeed hardware sources of truly random numbers based upon some physically random phenomenon such as thermal noise. They are in fact very slow, and as a result are often used to seed much faster pseudo-random number generators.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-13 00:03 -0800 |
| Message-ID | <tn9bk7$2fhh2$1@dont-email.me> |
| In reply to | #87839 |
On 12/12/2022 4:00 PM, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> Ike Naar <ike@sdf.org> writes: >>> On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote: >>>> long seed = random(); is perfectly readable and self documenting. >>> >>> The word choice is a bit unconventional. >>> A seed is most often used as an initial input to >>> a random number generator, not as the result of it. >> >> It's common to seed a PRNG with a random number. Preferably >> a true random number. > > If you can get a "true random number", you don't need a PRNG > (unless your source of true random numbers is slow or otherwise > resource-intensive). But it's rare to be able to get true random > numbers in the first place. > >> It wasn't uncommon in the early days of unix games to seed >> the PRNG with the current time in seconds since the Epoch. > > Which is hardly random. > Shake a big box containing a shit load of 16 sided dice up really good... Unplug a hole and shake it until a single die drops out. Hey, we just got a nibble! ;^) Shake and repeat. lol.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-13 14:39 +0200 |
| Message-ID | <tn9rpm$2go66$1@dont-email.me> |
| In reply to | #87839 |
13.12.2022 02:00 Keith Thompson kirjutas: > scott@slp53.sl.home (Scott Lurndal) writes: >> Ike Naar <ike@sdf.org> writes: >>> On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote: >>>> long seed = random(); is perfectly readable and self documenting. >>> >>> The word choice is a bit unconventional. >>> A seed is most often used as an initial input to >>> a random number generator, not as the result of it. >> >> It's common to seed a PRNG with a random number. Preferably >> a true random number. > > If you can get a "true random number", you don't need a PRNG > (unless your source of true random numbers is slow or otherwise > resource-intensive). In Linux there are /dev/random and /dev/urandom. The first one ought to be slower and more random (gathers "environmental noise from device drivers") than the other, although /dev/urandom is nowadays supposed to be also good for almost anything, including cryptographic purposes. I once had to fix a bug where my program stalled. It appeared I had thoughtlessly used /dev/random for filling some random pool, and as the program was run in a stripped-down Linux VM without any direct connection to physical hardware, the system ran out of random data for /dev/random and the program hanged indefinitely when trying to read it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-13 14:10 +0100 |
| Message-ID | <tn9tl0$2gspl$1@dont-email.me> |
| In reply to | #87839 |
On 13/12/2022 01:00, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> Ike Naar <ike@sdf.org> writes: >>> On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote: >>>> long seed = random(); is perfectly readable and self documenting. >>> >>> The word choice is a bit unconventional. >>> A seed is most often used as an initial input to >>> a random number generator, not as the result of it. >> >> It's common to seed a PRNG with a random number. Preferably >> a true random number. > > If you can get a "true random number", you don't need a PRNG > (unless your source of true random numbers is slow or otherwise > resource-intensive). But it's rare to be able to get true random > numbers in the first place. True random data - or at least high entropy data - is almost always slow. It also often has an awkward distribution (such as Binomial or Poisson, rather than convenient linear distribution). So the standard practice is to use the high entropy data to seed a pseudo-random number generator from your high entropy source. > >> It wasn't uncommon in the early days of unix games to seed >> the PRNG with the current time in seconds since the Epoch. > > Which is hardly random. > It makes no sense to call a seed "random" or not. It can be non-deterministic (and the current time in seconds is non-deterministic enough for a great many purposes - certainly for games). But only a distribution can be random, not a single number. Higher quality seeds with greater entropy combine multiple sources, such as the least-significant bit of temperature measurements, microsecond times between network packets or keyboard clicks, etc. (You have to be careful how you combine them - simply adding them is not a good idea!)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-13 14:59 +0000 |
| Message-ID | <Vq0mL.18267$9sn9.16654@fx17.iad> |
| In reply to | #87839 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: >> Ike Naar <ike@sdf.org> writes: >>>On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote: >>>> long seed = random(); is perfectly readable and self documenting. >>> >>>The word choice is a bit unconventional. >>>A seed is most often used as an initial input to >>>a random number generator, not as the result of it. >> >> It's common to seed a PRNG with a random number. Preferably >> a true random number. > >If you can get a "true random number", you don't need a PRNG >(unless your source of true random numbers is slow or otherwise >resource-intensive). But it's rare to be able to get true random >numbers in the first place. Well, we do have a TNRG on our chips. And as you point out, TRNG's are generally quite slow, so they're often used to seed PRNG's (either hardware based or software based). > >> It wasn't uncommon in the early days of unix games to seed >> the PRNG with the current time in seconds since the Epoch. > >Which is hardly random. Not particuarly, no. But effective for the simple purposes used.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-13 13:07 -0800 |
| Message-ID | <tnapi0$2jff0$2@dont-email.me> |
| In reply to | #87870 |
On 12/13/2022 6:59 AM, Scott Lurndal wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> scott@slp53.sl.home (Scott Lurndal) writes: >>> Ike Naar <ike@sdf.org> writes: >>>> On 2022-12-12, Scott Lurndal <scott@slp53.sl.home> wrote: >>>>> long seed = random(); is perfectly readable and self documenting. >>>> >>>> The word choice is a bit unconventional. >>>> A seed is most often used as an initial input to >>>> a random number generator, not as the result of it. >>> >>> It's common to seed a PRNG with a random number. Preferably >>> a true random number. >> >> If you can get a "true random number", you don't need a PRNG >> (unless your source of true random numbers is slow or otherwise >> resource-intensive). But it's rare to be able to get true random >> numbers in the first place. > > Well, we do have a TNRG on our chips. And as you point out, > TRNG's are generally quite slow, so they're often used to seed > PRNG's (either hardware based or software based). > >> >>> It wasn't uncommon in the early days of unix games to seed >>> the PRNG with the current time in seconds since the Epoch. >> >> Which is hardly random. > > Not particuarly, no. But effective for the simple purposes used. > Fwiw, check this shit out, and experiment in race conditions: https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/XiqELOEECAAJ ;^) lol.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-13 08:24 +0000 |
| Message-ID | <tn9crv$120t$1@gioia.aioe.org> |
| In reply to | #87833 |
Scott Lurndal <scott@slp53.sl.home> wrote: > "Most" programmers find uppercase characters in the > identifier are a productivity hit (more difficult > to type, for instance) and have no other redeeming > value. If you want to use camelCase or snake_case that's just fine, as long as it's consistent and readable. That's not the point. > I'll take 'rval' over "returnValue" every time. Exactly my point. Thanks for demonstrating. > long seed = random(); is perfectly readable and self documenting. At least it's using full English words, which is a step in the right direction.
[toc] | [prev] | [next] | [standalone]
Page 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web