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 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-14 12:17 -0800 |
| Message-ID | <tndavs$2s06f$1@dont-email.me> |
| In reply to | #87904 |
On 12/14/2022 5:11 AM, David Brown wrote: > On 14/12/2022 08:36, Juha Nieminen wrote: >> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>> - Almost always use namespace prefixes when using names inside a >>>>> namespace, even in code that's inside the same namespace. (This is >>>>> because when the namespace appears in the name, it makes it very >>>>> clear that the name is from that namespace and not a function-local >>>>> name, a class member, or a global name somewhere else.) >>>> >>>> In that case whats the point of having a namespace at all? You can >>>> achieve >>>> exactly the same result C style with function naming. Eg: instead of >>>> mylib::func() you can just call it mylib_func(). >>> >>> If you want to do that, go right ahead. >> >> In fact, I have noticed a rather interesting psychological phenomenon >> related to this. >> >> Many C++ programmers will fight tooth and nail to defend their practice >> of not writing namespace prefixes and the use of 'using' to allow them >> to do that... and the exact same people never, ever, ever complaining >> about having to write prefixes in names declared in many C libraries. > > Really? > > I wonder if you have very odd colleagues, or if you interpret things > differently from myself (and apparently some others in this thread). > > I use "using" locally in functions when it makes code simpler and > clearer, because it makes names shorter and has less clutter. It also > makes it clearer that I am "using" a particular imported namespace. If > I have a namespace called "display", and I am writing a function that > uses the display, it is a /good/ thing to write "using namespace > display;" in that function. It is a /good/ thing to write "clear();" or > "get_dimensions()" rather than "display::clear();" and > "display::get_dimensions()". > > Obviously if there is ambiguity, you need to use namespace prefixes. > > In C, people /do/ grumble about long and awkward names with no scoping. > They minimise the problem by using short abbreviations for their > prefixes, and they don't complain too much because it is pointless to > complain too much since there is no alternative. [...] pthread_* pthread_mutex_* I have seen programmers get pissed off about having to write that prefix. I have seen some of them do crazy shit like: #define mtx pthread_mutex_t #define mtxint pthread_mutex_init #define mtxlck pthread_mutex_lock [...] I said wtf is a mtx? Oh, its a posix threads mutex. Okay.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-15 08:53 +0100 |
| Message-ID | <tnejqm$31sp0$1@dont-email.me> |
| In reply to | #87935 |
On 14/12/2022 21:17, Chris M. Thomasson wrote: > On 12/14/2022 5:11 AM, David Brown wrote: >> On 14/12/2022 08:36, Juha Nieminen wrote: >>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>>> - Almost always use namespace prefixes when using names inside a >>>>>> namespace, even in code that's inside the same namespace. (This is >>>>>> because when the namespace appears in the name, it makes it very >>>>>> clear that the name is from that namespace and not a function-local >>>>>> name, a class member, or a global name somewhere else.) >>>>> >>>>> In that case whats the point of having a namespace at all? You can >>>>> achieve >>>>> exactly the same result C style with function naming. Eg: instead of >>>>> mylib::func() you can just call it mylib_func(). >>>> >>>> If you want to do that, go right ahead. >>> >>> In fact, I have noticed a rather interesting psychological phenomenon >>> related to this. >>> >>> Many C++ programmers will fight tooth and nail to defend their practice >>> of not writing namespace prefixes and the use of 'using' to allow them >>> to do that... and the exact same people never, ever, ever complaining >>> about having to write prefixes in names declared in many C libraries. >> >> Really? >> >> I wonder if you have very odd colleagues, or if you interpret things >> differently from myself (and apparently some others in this thread). >> >> I use "using" locally in functions when it makes code simpler and >> clearer, because it makes names shorter and has less clutter. It also >> makes it clearer that I am "using" a particular imported namespace. >> If I have a namespace called "display", and I am writing a function >> that uses the display, it is a /good/ thing to write "using namespace >> display;" in that function. It is a /good/ thing to write "clear();" >> or "get_dimensions()" rather than "display::clear();" and >> "display::get_dimensions()". >> >> Obviously if there is ambiguity, you need to use namespace prefixes. >> >> In C, people /do/ grumble about long and awkward names with no >> scoping. They minimise the problem by using short abbreviations for >> their prefixes, and they don't complain too much because it is >> pointless to complain too much since there is no alternative. > [...] > > pthread_* > pthread_mutex_* > > I have seen programmers get pissed off about having to write that > prefix. I have seen some of them do crazy shit like: > > #define mtx pthread_mutex_t > #define mtxint pthread_mutex_init > #define mtxlck pthread_mutex_lock > [...] > > I said wtf is a mtx? Oh, its a posix threads mutex. Okay. Yes, people do that kind of thing in C. I've even seen things like : #define UL(id) (user_library_ ## id) and then "UL(foo)(123);" instead of "user_library_foo(123);" I'm going to go out on a limb and guess that Juha would like that even less than a "using namespace" clause! A clear benefit of C++ over C, even for those that prefer a simpler language and stick mostly to the C-subset of C++, is that you have hierarchical naming that follows the structure of your code - you can have "using" locally in a function, unlike preprocessor hacks like these.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-16 21:41 -0800 |
| Message-ID | <tnjkpf$3jjms$5@dont-email.me> |
| In reply to | #87944 |
On 12/14/2022 11:53 PM, David Brown wrote: > On 14/12/2022 21:17, Chris M. Thomasson wrote: >> On 12/14/2022 5:11 AM, David Brown wrote: >>> On 14/12/2022 08:36, Juha Nieminen wrote: >>>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>>>>> - Almost always use namespace prefixes when using names inside a >>>>>>> namespace, even in code that's inside the same namespace. (This is >>>>>>> because when the namespace appears in the name, it makes it very >>>>>>> clear that the name is from that namespace and not a function-local >>>>>>> name, a class member, or a global name somewhere else.) >>>>>> >>>>>> In that case whats the point of having a namespace at all? You can >>>>>> achieve >>>>>> exactly the same result C style with function naming. Eg: instead of >>>>>> mylib::func() you can just call it mylib_func(). >>>>> >>>>> If you want to do that, go right ahead. >>>> >>>> In fact, I have noticed a rather interesting psychological phenomenon >>>> related to this. >>>> >>>> Many C++ programmers will fight tooth and nail to defend their practice >>>> of not writing namespace prefixes and the use of 'using' to allow them >>>> to do that... and the exact same people never, ever, ever complaining >>>> about having to write prefixes in names declared in many C libraries. >>> >>> Really? >>> >>> I wonder if you have very odd colleagues, or if you interpret things >>> differently from myself (and apparently some others in this thread). >>> >>> I use "using" locally in functions when it makes code simpler and >>> clearer, because it makes names shorter and has less clutter. It >>> also makes it clearer that I am "using" a particular imported >>> namespace. If I have a namespace called "display", and I am writing a >>> function that uses the display, it is a /good/ thing to write "using >>> namespace display;" in that function. It is a /good/ thing to write >>> "clear();" or "get_dimensions()" rather than "display::clear();" and >>> "display::get_dimensions()". >>> >>> Obviously if there is ambiguity, you need to use namespace prefixes. >>> >>> In C, people /do/ grumble about long and awkward names with no >>> scoping. They minimise the problem by using short abbreviations for >>> their prefixes, and they don't complain too much because it is >>> pointless to complain too much since there is no alternative. >> [...] >> >> pthread_* >> pthread_mutex_* >> >> I have seen programmers get pissed off about having to write that >> prefix. I have seen some of them do crazy shit like: >> >> #define mtx pthread_mutex_t >> #define mtxint pthread_mutex_init >> #define mtxlck pthread_mutex_lock >> [...] >> >> I said wtf is a mtx? Oh, its a posix threads mutex. Okay. > > Yes, people do that kind of thing in C. I've even seen things like : > > #define UL(id) (user_library_ ## id) > > and then "UL(foo)(123);" instead of "user_library_foo(123);" Oh god. I have seen macro tricks before, chaos lib... Wiping sweat off of brow... Have you seen that heap of genius? Wow. I have posted some crazy macro shit on this group, or was it comp.lang.c... Have to do a search. Sorry. > > I'm going to go out on a limb and guess that Juha would like that even > less than a "using namespace" clause! > > A clear benefit of C++ over C, even for those that prefer a simpler > language and stick mostly to the C-subset of C++, is that you have > hierarchical naming that follows the structure of your code - you can > have "using" locally in a function, unlike preprocessor hacks like these. > ct::vector_field vs ct_vector_field I love C, but C++ namespaces are very great! Love them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-17 15:34 +0100 |
| Message-ID | <tnkk0t$3m0it$1@dont-email.me> |
| In reply to | #87986 |
On 17/12/2022 06:41, Chris M. Thomasson wrote: > On 12/14/2022 11:53 PM, David Brown wrote: >> On 14/12/2022 21:17, Chris M. Thomasson wrote: >>> On 12/14/2022 5:11 AM, David Brown wrote: >>>> In C, people /do/ grumble about long and awkward names with no >>>> scoping. They minimise the problem by using short abbreviations >>>> for their prefixes, and they don't complain too much because it is >>>> pointless to complain too much since there is no alternative. >>> [...] >>> >>> pthread_* >>> pthread_mutex_* >>> >>> I have seen programmers get pissed off about having to write that >>> prefix. I have seen some of them do crazy shit like: >>> >>> #define mtx pthread_mutex_t >>> #define mtxint pthread_mutex_init >>> #define mtxlck pthread_mutex_lock >>> [...] >>> >>> I said wtf is a mtx? Oh, its a posix threads mutex. Okay. >> >> Yes, people do that kind of thing in C. I've even seen things like : >> >> #define UL(id) (user_library_ ## id) >> >> and then "UL(foo)(123);" instead of "user_library_foo(123);" > > Oh god. I have seen macro tricks before, chaos lib... Wiping sweat off > of brow... Have you seen that heap of genius? Wow. I have posted some > crazy macro shit on this group, or was it comp.lang.c... Have to do a > search. Sorry. > >> >> I'm going to go out on a limb and guess that Juha would like that even >> less than a "using namespace" clause! >> >> A clear benefit of C++ over C, even for those that prefer a simpler >> language and stick mostly to the C-subset of C++, is that you have >> hierarchical naming that follows the structure of your code - you can >> have "using" locally in a function, unlike preprocessor hacks like these. >> > > > ct::vector_field > > vs > > ct_vector_field > > I love C, but C++ namespaces are very great! Love them. And if the original namespace is actually "Chris_M_Thomasson_lib", you can write: namespace ct = Chris_M_Thomasson_lib; and then : ct::vector_field rather than : Chris_M_Thomasson_lib::vector_field If you are going to be using "vector_field" a lot and you think it is neater to have a local abbreviation, you can write : using vf = ct::vector_field; // A type or constexpr auto vf = ct::vector_field; // A function These abbreviations are much better than using pre-processor macros, because the they are structured and specific. (It would be nicer, perhaps, if there were a single way to handle different kinds of things, instead of separate syntaxes for namespaces, functions and types.)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-17 13:27 -0800 |
| Message-ID | <tnlc8s$3ocs5$4@dont-email.me> |
| In reply to | #87991 |
On 12/17/2022 6:34 AM, David Brown wrote: > On 17/12/2022 06:41, Chris M. Thomasson wrote: >> On 12/14/2022 11:53 PM, David Brown wrote: >>> On 14/12/2022 21:17, Chris M. Thomasson wrote: >>>> On 12/14/2022 5:11 AM, David Brown wrote: > >>>>> In C, people /do/ grumble about long and awkward names with no >>>>> scoping. They minimise the problem by using short abbreviations >>>>> for their prefixes, and they don't complain too much because it is >>>>> pointless to complain too much since there is no alternative. >>>> [...] >>>> >>>> pthread_* >>>> pthread_mutex_* >>>> >>>> I have seen programmers get pissed off about having to write that >>>> prefix. I have seen some of them do crazy shit like: >>>> >>>> #define mtx pthread_mutex_t >>>> #define mtxint pthread_mutex_init >>>> #define mtxlck pthread_mutex_lock >>>> [...] >>>> >>>> I said wtf is a mtx? Oh, its a posix threads mutex. Okay. >>> >>> Yes, people do that kind of thing in C. I've even seen things like : >>> >>> #define UL(id) (user_library_ ## id) >>> >>> and then "UL(foo)(123);" instead of "user_library_foo(123);" >> >> Oh god. I have seen macro tricks before, chaos lib... Wiping sweat off >> of brow... Have you seen that heap of genius? Wow. I have posted some >> crazy macro shit on this group, or was it comp.lang.c... Have to do a >> search. Sorry. >> >>> >>> I'm going to go out on a limb and guess that Juha would like that >>> even less than a "using namespace" clause! >>> >>> A clear benefit of C++ over C, even for those that prefer a simpler >>> language and stick mostly to the C-subset of C++, is that you have >>> hierarchical naming that follows the structure of your code - you can >>> have "using" locally in a function, unlike preprocessor hacks like >>> these. >>> >> >> >> ct::vector_field >> >> vs >> >> ct_vector_field >> >> I love C, but C++ namespaces are very great! Love them. > > And if the original namespace is actually "Chris_M_Thomasson_lib", you > can write: > > namespace ct = Chris_M_Thomasson_lib; > > and then : > > ct::vector_field > > rather than : > > Chris_M_Thomasson_lib::vector_field > > If you are going to be using "vector_field" a lot and you think it is > neater to have a local abbreviation, you can write : > > using vf = ct::vector_field; // A type > > or > > constexpr auto vf = ct::vector_field; // A function > > These abbreviations are much better than using pre-processor macros, > because the they are structured and specific. (It would be nicer, > perhaps, if there were a single way to handle different kinds of things, > instead of separate syntaxes for namespaces, functions and types.) > > > Agreed! These are some of the reasons why I love C++ namespaces.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-17 13:32 -0800 |
| Message-ID | <tnlch0$3ocs5$5@dont-email.me> |
| In reply to | #87991 |
On 12/17/2022 6:34 AM, David Brown wrote: > On 17/12/2022 06:41, Chris M. Thomasson wrote: >> On 12/14/2022 11:53 PM, David Brown wrote: >>> On 14/12/2022 21:17, Chris M. Thomasson wrote: >>>> On 12/14/2022 5:11 AM, David Brown wrote: > >>>>> In C, people /do/ grumble about long and awkward names with no >>>>> scoping. They minimise the problem by using short abbreviations >>>>> for their prefixes, and they don't complain too much because it is >>>>> pointless to complain too much since there is no alternative. >>>> [...] >>>> >>>> pthread_* >>>> pthread_mutex_* >>>> >>>> I have seen programmers get pissed off about having to write that >>>> prefix. I have seen some of them do crazy shit like: >>>> >>>> #define mtx pthread_mutex_t >>>> #define mtxint pthread_mutex_init >>>> #define mtxlck pthread_mutex_lock >>>> [...] >>>> >>>> I said wtf is a mtx? Oh, its a posix threads mutex. Okay. >>> >>> Yes, people do that kind of thing in C. I've even seen things like : >>> >>> #define UL(id) (user_library_ ## id) >>> >>> and then "UL(foo)(123);" instead of "user_library_foo(123);" >> >> Oh god. I have seen macro tricks before, chaos lib... Wiping sweat off >> of brow... Have you seen that heap of genius? Wow. I have posted some >> crazy macro shit on this group, or was it comp.lang.c... Have to do a >> search. Sorry. >> >>> >>> I'm going to go out on a limb and guess that Juha would like that >>> even less than a "using namespace" clause! >>> >>> A clear benefit of C++ over C, even for those that prefer a simpler >>> language and stick mostly to the C-subset of C++, is that you have >>> hierarchical naming that follows the structure of your code - you can >>> have "using" locally in a function, unlike preprocessor hacks like >>> these. >>> >> >> >> ct::vector_field >> >> vs >> >> ct_vector_field >> >> I love C, but C++ namespaces are very great! Love them. > > And if the original namespace is actually "Chris_M_Thomasson_lib", you > can write: > > namespace ct = Chris_M_Thomasson_lib; > > and then : > > ct::vector_field > > rather than : > > Chris_M_Thomasson_lib::vector_field > > If you are going to be using "vector_field" a lot and you think it is > neater to have a local abbreviation, you can write : > > using vf = ct::vector_field; // A type > > or > > constexpr auto vf = ct::vector_field; // A function > > These abbreviations are much better than using pre-processor macros, > because the they are structured and specific. (It would be nicer, > perhaps, if there were a single way to handle different kinds of things, > instead of separate syntaxes for namespaces, functions and types.) > > > Iirc, I have some old posts that use namespace aliases. namespace ct_exp = ct::experimental::ver_0_0_0_1
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 07:58 +0000 |
| Message-ID | <tnp5iv$u80$1@gioia.aioe.org> |
| In reply to | #87944 |
David Brown <david.brown@hesbynett.no> wrote: > Yes, people do that kind of thing in C. I've even seen things like : > > #define UL(id) (user_library_ ## id) > > and then "UL(foo)(123);" instead of "user_library_foo(123);" > > I'm going to go out on a limb and guess that Juha would like that even > less than a "using namespace" clause! You are correct in that. If I were to be forced at gunpoint to choose between the two, I would choose 'using namespace'.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 07:46 +0000 |
| Message-ID | <tnp4t9$m2m$1@gioia.aioe.org> |
| In reply to | #87904 |
David Brown <david.brown@hesbynett.no> wrote: > I use "using" locally in functions when it makes code simpler and > clearer, because it makes names shorter and has less clutter. And there we go again with the brevity argument. Again, and again, and again, and again. Ad infinitum. Sorter code is not necessarily clearer code. In fact, quite often it's the opposite. Where does this strange concept come from, that shorter is clearer? I don't see you using abbreviations in your English prose. Why not? Because if you abbreviated every single word in your text, it would become near illegible. That's why. You use full English words because your text becomes more legible that way. Why is it different in program code? Well, it isn't. Also program code becomes more legible when it's actually stating, using full English words, what it's doing, instead of being full of cryptic abbreviations and acronyms. The brevity-over-clarity style of programming will probably be a curse in programming for as long as humanity will exist and keep writing programs. > It also > makes it clearer that I am "using" a particular imported namespace. Do you know what makes it even clearer? Saying so in the names from that namespace. The reader doesn't have to guess when it's explicitly stated. I will never understand why so many programmers fight tooth and nail against this concept. > If > I have a namespace called "display", and I am writing a function that > uses the display, it is a /good/ thing to write "using namespace > display;" in that function. It is a /good/ thing to write "clear();" or > "get_dimensions()" rather than "display::clear();" and > "display::get_dimensions()". I see absolutely nothing "good" about it. I can only see negatives. How would I know what the 'clear()' is doing, or where it comes from? Maybe it's clearing the data structures of this class? How would I know? You seem completely unable to position yourself in the shoes of a third-party reading your code. > People don't like having to write long prefixes when it is obvious from > the context of the code which library or set of identifiers you are > using. But that's the problem: It may be obvious *to you*, the person writing the code. It may be far from obvious to someone else who is reading your code and doesn't know in advance what it's doing. When you specify the prefixes you are helping the reader understand what that name is and where it comes from.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-19 14:55 +0200 |
| Message-ID | <tnpn0d$a3gh$1@dont-email.me> |
| In reply to | #88025 |
19.12.2022 09:46 Juha Nieminen kirjutas:
> David Brown <david.brown@hesbynett.no> wrote:
>> I use "using" locally in functions when it makes code simpler and
>> clearer, because it makes names shorter and has less clutter.
>
> And there we go again with the brevity argument. Again, and again, and
> again, and again. Ad infinitum.
>
> Sorter code is not necessarily clearer code. In fact, quite often it's
> the opposite.
And longer code is not necessarily clearer code. Hereby I present a
snippet of actual code from a former coworker who strongly believed in
long self-explanatory names. He also believed in 76-char line limit.
These goals are a bit contradictory, I guess that's why there appear
copies of variables with shorter names inside the function, and maybe
this also explains occasional one-letter function names like 'q'.
The function Validate_ObjectsSetCardinalityEquality_type1_helper1() is
called once from the rest of the program, from a function with the name
- you guessed it - Validate_ObjectsSetCardinalityEquality_type1() and
which looks mostly the same.
He was also very keen on program speed and optimizations, I guess that's
why the functions are marked 'inline'. Never mind pass of string
arguments by value, or using these two full functions for making a
single integer comparison in the first place.
inline std::string q(const std::string& s) {
return ("\"" + s + "\"");
}
inline void Validate_ObjectsSetCardinalityEquality_type1_helper1(
int number_of_objects_in_the_1_comparable,
int number_of_objects_in_the_2_comparable,
std::string name_of_the_1_comparable,
std::string name_of_the_2_comparable,
std::string type_name_of_the_1_comparable,
std::string type_name_of_the_2_comparable
) {
int n_1 = number_of_objects_in_the_1_comparable;
int n_2 = number_of_objects_in_the_2_comparable;
std::string AssertionFailureMessage = "";
if (n_1 != n_2) {
std::string name1 = name_of_the_1_comparable;
std::string name2 = name_of_the_2_comparable;
std::string name2a = "";
std::string t_name1 = type_name_of_the_1_comparable;
std::string t_name2 = type_name_of_the_2_comparable;
name2a = name2;
if (!type_name_of_the_1_comparable.empty()) {
name1 = ", " + q(name1) + ", ";
} //if
else {
name1 = " " + q(name1) + " ";
} //else
if (!type_name_of_the_2_comparable.empty()) {
name2 = ", " + q(name2) + ", ";
name2a = ", " + q(name2) + ", ";
} //if
else {
name2 = " " + q(name2) + " ";
name2a = " " + q(name2) + ", ";
} //else
AssertionFailureMessage = "\n\n"
"The number of objects at " +
t_name1 + name1 + "(==" + str(n_1) + ")\n"
"did not match with the number "
"of objects at " +
t_name2 + name2 + "(==" + str(n_2) + ").\n"
"It is assumed that both, the " +
t_name1 + name1 + "\n"
"and the " +
t_name2 + name2a + " "
"have exactly the same\n"
"number of objects."
"\n\n";
throw AdrasteaAssertionFailure(AssertionFailureMessage);
} // if
} // Validate_ObjectsSetCardinalityEquality_type1_helper1()
;
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-12-19 15:24 +0000 |
| Message-ID | <tnpvn4$1bt6$1@gioia.aioe.org> |
| In reply to | #88040 |
Paavo Helde <eesnimi@osa.pri.ee> wrote:
> And longer code is not necessarily clearer code. Hereby I present a
> snippet of actual code from a former coworker who strongly believed in
> long self-explanatory names.
Rather obviously length doesn't automatically make it clearer (which
is why I have been repeating that length doesn't matter). You have
to choose the words being used for the name so as to convey clearly
to the reader what it is.
'convert()' is not a very good name because it doesn't say what it's
converting, and into what.
'convert_something_into_something()' is a ridiculous name because it's
as bad as the first one above, plus contains completely useless
redundancy that doesn't help understand what it's doing.
'convert_to_utf8()' is better, although only depending on the context.
It's saying what it's converting to, but it doesn't say what it's
converting from. Sounds like a (heavily) overloaded function, but in
general I don't like those being used for no good reason, and thus
I would prefer if the function actually says what it's converting from,
like for example
'convert_to_utf8_from_utf16()'
This starts being a good name because it expresses relatively clearly
what it's doing (although it does not express its parameter types)
and doesn't really contain any redundancy. (Whether you also want to
express the type of the parameters in the name might be more up to
discussion. Here I'm not extraordinarily strongly opinioned. Might
be more relevant if there are several versions of the function for
different string types.)
> He also believed in 76-char line limit.
There's really no reason to use such a limit, and there hasn't really been
in a rather long time. Quite obviously if your names become longer then
you want a bit wider lines. (Well, as long as you don't go overboard.
I have seen code that breaks the 200 characters per line mark, and
that starts being a bit ridiculous, even when your editor is that wide.)
> He was also very keen on program speed and optimizations, I guess that's
> why the functions are marked 'inline'. Never mind pass of string
> arguments by value, or using these two full functions for making a
> single integer comparison in the first place.
>
> inline std::string q(const std::string& s) {
> return ("\"" + s + "\"");
> }
He also seems to commit the typical mistake of thinking that 'inline'
implies 'static' (which, AFAIK, it definitely does not).
(Horribly named function, btw.)
> inline void Validate_ObjectsSetCardinalityEquality_type1_helper1(
The main problem I see here is that the name might contain lots of words,
but most of those words don't really clarify what this is doing. Maybe
it's clearer in context, but all by itself it's hard to guess what that
'type1' or 'helper1' is supposed to convey.
Using full English words doesn't by itself guarantee clarity. Obviously
you have to choose those words appropriately to convey to the reader as
clearly as possible what the thing is for.
> int n_1 = number_of_objects_in_the_1_comparable;
> int n_2 = number_of_objects_in_the_2_comparable;
> std::string AssertionFailureMessage = "";
Inconsistent case usage is also a sin in programming.
Choose a consistent naming style and stick to it.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-19 22:03 +0200 |
| Message-ID | <tnqg2n$e53j$1@dont-email.me> |
| In reply to | #88050 |
19.12.2022 17:24 Juha Nieminen kirjutas: > Paavo Helde <eesnimi@osa.pri.ee> wrote: >> And longer code is not necessarily clearer code. Hereby I present a >> snippet of actual code from a former coworker who strongly believed in >> long self-explanatory names. > > Rather obviously length doesn't automatically make it clearer (which > is why I have been repeating that length doesn't matter). You have > to choose the words being used for the name so as to convey clearly > to the reader what it is. Agreed. > > 'convert()' is not a very good name because it doesn't say what it's > converting, and into what. > > 'convert_something_into_something()' is a ridiculous name because it's > as bad as the first one above, plus contains completely useless > redundancy that doesn't help understand what it's doing. > > 'convert_to_utf8()' is better, although only depending on the context. > It's saying what it's converting to, but it doesn't say what it's > converting from. Sounds like a (heavily) overloaded function, but in > general I don't like those being used for no good reason, and thus > I would prefer if the function actually says what it's converting from, > like for example > > 'convert_to_utf8_from_utf16()' > > This starts being a good name because it expresses relatively clearly > what it's doing (although it does not express its parameter types) > and doesn't really contain any redundancy. (Whether you also want to > express the type of the parameters in the name might be more up to > discussion. Here I'm not extraordinarily strongly opinioned. Might > be more relevant if there are several versions of the function for > different string types.) Ah, I have written a bunch of these conversion functions, and pondered about their names quite a lot. This is what I have arrived at: Utf2Win - UTF-8 to UTF-16 Utf2WinFileName - same, plus converts slashes to backslashes Win2Utf - reverse Win2UtfFileName - reverse These names are fine for my taste, but probably too short for yours. These names reflect their usage context, namely converting strings for the Windows API and back. > >> He also believed in 76-char line limit. > > There's really no reason to use such a limit, and there hasn't really been > in a rather long time. I could not get clear reasons about this from him. Probably he felt himself good after he managed to squeeze its code into this absurd limit. I recall some his code with deeply nested if-else blocks where the lines contained of 50 chars of indentation and 20 chars of code. > Quite obviously if your names become longer then > you want a bit wider lines. (Well, as long as you don't go overboard. > I have seen code that breaks the 200 characters per line mark, and > that starts being a bit ridiculous, even when your editor is that wide.) >> inline void Validate_ObjectsSetCardinalityEquality_type1_helper1( > > The main problem I see here is that the name might contain lots of words, > but most of those words don't really clarify what this is doing. Maybe > it's clearer in context, but all by itself it's hard to guess what that > 'type1' or 'helper1' is supposed to convey. No, it was not better in context. There are no type2 or helper2. There are also no sets and no cardinalities involved in this part of the program. A better name for that function would be ThrowIfNotEqual. Though I do not see any need for such a function, I would just throw an exception where needed.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-19 20:38 +0000 |
| Message-ID | <8Z3oL.38679$t5W7.19522@fx13.iad> |
| In reply to | #88074 |
Paavo Helde <eesnimi@osa.pri.ee> writes: >19.12.2022 17:24 Juha Nieminen kirjutas: >> Paavo Helde <eesnimi@osa.pri.ee> wrote: >>> And longer code is not necessarily clearer code. Hereby I present a >>> snippet of actual code from a former coworker who strongly believed in >>> long self-explanatory names. >> >> Rather obviously length doesn't automatically make it clearer (which >> is why I have been repeating that length doesn't matter). You have >> to choose the words being used for the name so as to convey clearly >> to the reader what it is. > >Agreed. > >> >> 'convert()' is not a very good name because it doesn't say what it's >> converting, and into what. >> >> 'convert_something_into_something()' is a ridiculous name because it's >> as bad as the first one above, plus contains completely useless >> redundancy that doesn't help understand what it's doing. >> >> 'convert_to_utf8()' is better, although only depending on the context. >> It's saying what it's converting to, but it doesn't say what it's >> converting from. Sounds like a (heavily) overloaded function, but in >> general I don't like those being used for no good reason, and thus >> I would prefer if the function actually says what it's converting from, >> like for example >> >> 'convert_to_utf8_from_utf16()' For this, I'd probably use c_utf8 string; string += c_utf8::from_utf16(utf16arg); But only if I ever programmed on windows, which will never happen.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-12-19 22:54 +0200 |
| Message-ID | <tnqj33$e909$2@dont-email.me> |
| In reply to | #88075 |
19.12.2022 22:38 Scott Lurndal kirjutas: > Paavo Helde <eesnimi@osa.pri.ee> writes: >> 19.12.2022 17:24 Juha Nieminen kirjutas: >>> 'convert_to_utf8_from_utf16()' > > For this, I'd probably use > > c_utf8 string; > > string += c_utf8::from_utf16(utf16arg); And what does 'c_' mean? Apparently another "universally understood abbreviation" which I would not know without context.
[toc] | [prev] | [next] | [standalone]
| From | Tony Oliver <guinness.tony@gmail.com> |
|---|---|
| Date | 2022-12-19 16:38 -0800 |
| Message-ID | <e23b1fb6-2f44-445a-91e7-c10606d0f110n@googlegroups.com> |
| In reply to | #88078 |
On Monday, 19 December 2022 at 20:55:13 UTC, Paavo Helde wrote: > 19.12.2022 22:38 Scott Lurndal kirjutas: > > Paavo Helde <ees...@osa.pri.ee> writes: > >> 19.12.2022 17:24 Juha Nieminen kirjutas: > >>> 'convert_to_utf8_from_utf16()' > > > > For this, I'd probably use > > > > c_utf8 string; > > > > string += c_utf8::from_utf16(utf16arg); > And what does 'c_' mean? Apparently another "universally understood > abbreviation" which I would not know without context. +1
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-12-19 19:18 -0800 |
| Message-ID | <tnr9ip$gbuf$6@dont-email.me> |
| In reply to | #88078 |
On 12/19/2022 12:54 PM, Paavo Helde wrote: > 19.12.2022 22:38 Scott Lurndal kirjutas: >> Paavo Helde <eesnimi@osa.pri.ee> writes: >>> 19.12.2022 17:24 Juha Nieminen kirjutas: >>>> 'convert_to_utf8_from_utf16()' >> >> For this, I'd probably use >> >> c_utf8 string; >> >> string += c_utf8::from_utf16(utf16arg); > > And what does 'c_' mean? Apparently another "universally understood > abbreviation" which I would not know without context. > > Ala c_str? not sure.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-12-20 14:51 +0000 |
| Message-ID | <KZjoL.40323$t5W7.20337@fx13.iad> |
| In reply to | #88086 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 12/19/2022 12:54 PM, Paavo Helde wrote: >> 19.12.2022 22:38 Scott Lurndal kirjutas: >>> Paavo Helde <eesnimi@osa.pri.ee> writes: >>>> 19.12.2022 17:24 Juha Nieminen kirjutas: >>>>> 'convert_to_utf8_from_utf16()' >>> >>> For this, I'd probably use >>> >>> c_utf8 string; >>> >>> string += c_utf8::from_utf16(utf16arg); >> >> And what does 'c_' mean? Apparently another "universally understood >> abbreviation" which I would not know without context. >> >> > >Ala c_str? not sure. A convention used by a large project back around 1990. A visual indication that the type is a class at a time before IDEs.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-12-20 08:23 +0100 |
| Message-ID | <tnrnu3$kkv6$1@dont-email.me> |
| In reply to | #88078 |
On 19/12/2022 21:54, Paavo Helde wrote: > 19.12.2022 22:38 Scott Lurndal kirjutas: >> Paavo Helde <eesnimi@osa.pri.ee> writes: >>> 19.12.2022 17:24 Juha Nieminen kirjutas: >>>> 'convert_to_utf8_from_utf16()' >> >> For this, I'd probably use >> >> c_utf8 string; >> >> string += c_utf8::from_utf16(utf16arg); > > And what does 'c_' mean? Apparently another "universally understood > abbreviation" which I would not know without context. > I'd guess it meant "C string". But presumably if you had to read or use Scott's code, you /would/ have the context, and then you would know what it meant.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-12-20 17:52 +0100 |
| Message-ID | <tnsp86$nvtn$1@dont-email.me> |
| In reply to | #88075 |
On 19 Dec 2022 21:38, Scott Lurndal wrote:
> Paavo Helde <eesnimi@osa.pri.ee> writes:
>> 19.12.2022 17:24 Juha Nieminen kirjutas:
>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>> And longer code is not necessarily clearer code. Hereby I present a
>>>> snippet of actual code from a former coworker who strongly believed in
>>>> long self-explanatory names.
>>>
>>> Rather obviously length doesn't automatically make it clearer (which
>>> is why I have been repeating that length doesn't matter). You have
>>> to choose the words being used for the name so as to convey clearly
>>> to the reader what it is.
>>
>> Agreed.
>>
>>>
>>> 'convert()' is not a very good name because it doesn't say what it's
>>> converting, and into what.
>>>
>>> 'convert_something_into_something()' is a ridiculous name because it's
>>> as bad as the first one above, plus contains completely useless
>>> redundancy that doesn't help understand what it's doing.
>>>
>>> 'convert_to_utf8()' is better, although only depending on the context.
>>> It's saying what it's converting to, but it doesn't say what it's
>>> converting from. Sounds like a (heavily) overloaded function, but in
>>> general I don't like those being used for no good reason, and thus
>>> I would prefer if the function actually says what it's converting from,
>>> like for example
>>>
>>> 'convert_to_utf8_from_utf16()'
>
> For this, I'd probably use
>
> c_utf8 string;
>
> string += c_utf8::from_utf16(utf16arg);
>
> But only if I ever programmed on windows, which will never happen.
Current choice is a namespace called `u8` for brevity, like
namespace u8 {
template< class Unit_iterator >
constexpr auto to_sequence_at( const Unit_iterator it, const
char32_t code )
-> int
{
if( code < 0x80 ) { // 7 bits as 7
*(it + 0) = Byte( code );
return 1;
} else if( code < 0x800 ) { // 11 bits as 5 + 6
char32_t bits = code;
*(it + 1) = bits & continuation_bytes::value_bits_mask;
// 6
bits >>= continuation_bytes::n_value_bits;
*(it + 0) = Byte( 0b1100'0000 | bits );
// 5
return 2;
} else if( code < 0x10000 ) { // 16 bits as 4 + 6 + 6
char32_t bits = code;
*(it + 2) = bits & continuation_bytes::value_bits_mask;
// 6
bits >>= continuation_bytes::n_value_bits;
*(it + 1) = bits & continuation_bytes::value_bits_mask;
// 6
bits >>= continuation_bytes::n_value_bits;
*(it + 0) = Byte( 0b1110'0000 | bits );
// 4
return 3;
} else if( code < 0x110000 ) { // 21 bits as 3 + 6 + 6 + 6
char32_t bits = code;
*(it + 3) = bits & continuation_bytes::value_bits_mask;
// 6
bits >>= continuation_bytes::n_value_bits;
*(it + 2) = bits & continuation_bytes::value_bits_mask;
// 6
bits >>= continuation_bytes::n_value_bits;
*(it + 1) = bits & continuation_bytes::value_bits_mask;
// 6
bits >>= continuation_bytes::n_value_bits;
*(it + 0) = Byte( 0b1111'0000 | bits );
// 3
return 4;
} else {
FSM_FAIL( "Invalid Unicode code point (≥ 0x110000)." );
}
for( ;; ) {} // Should never get here.
}
}
I don't think I've /tested/ that code. Possibly it doesn't work. But
that's just a silly detail; the main question is whether there's really
any point in such manual loop unrolling?
- Alf
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-12-20 17:56 +0100 |
| Message-ID | <tnspfl$nvtn$2@dont-email.me> |
| In reply to | #88142 |
On 20 Dec 2022 17:52, Alf P. Steinbach wrote: > [code] The code was nicely formatted, including comments line-up, before posting. It's evidently Thunderbird fouling up things. Maintained by script kiddies, no doubt, because WE are too lazy to do such things. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Ralf Goertz <me@myprovider.invalid> |
|---|---|
| Date | 2022-12-21 11:22 +0100 |
| Message-ID | <tnumoi$vroi$1@dont-email.me> |
| In reply to | #88143 |
Am Tue, 20 Dec 2022 17:56:21 +0100 schrieb "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: > On 20 Dec 2022 17:52, Alf P. Steinbach wrote: > > [code] > > The code was nicely formatted, including comments line-up, before > posting. It's evidently Thunderbird fouling up things. Maintained by > script kiddies, no doubt, because WE are too lazy to do such things. It came to me nicely formatted (except for added line breaks in long lines). So I guess there is some other problem.
[toc] | [prev] | [next] | [standalone]
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
Back to top | Article view | comp.lang.c++
csiph-web