Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #89514 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2023-03-07 15:38 -0600 |
| Last post | 2023-04-06 00:42 -0700 |
| Articles | 20 on this page of 146 — 22 participants |
Back to article view | Back to comp.lang.c++
"C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-03-07 15:38 -0600
Re: "C++ on the Move" by Darryl K. Taft legalize+jeeves@mail.xmission.com (Richard) - 2023-03-07 22:08 +0000
Re: "C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-03-07 16:25 -0600
Re: "C++ on the Move" by Darryl K. Taft legalize+jeeves@mail.xmission.com (Richard) - 2023-03-07 23:10 +0000
Re: "C++ on the Move" by Darryl K. Taft Paavo Helde <eesnimi@osa.pri.ee> - 2023-03-08 08:40 +0200
Re: "C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-05 19:30 -0500
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-07 23:21 -0800
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-08 16:10 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-08 19:47 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-08 11:21 -0800
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-08 19:49 +0000
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-08 12:08 -0800
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 09:52 -0800
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-08 10:18 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-08 20:45 +0100
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-08 19:20 +0100
Re: "C++ on the Move" by Darryl K. Taft James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-03-08 14:10 -0500
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-08 22:34 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 14:29 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 00:59 +0100
Re: "C++ on the Move" by Darryl K. Taft James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-03-08 18:11 -0500
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 12:28 -0800
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-08 12:48 -0800
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-08 22:40 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 01:12 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 16:27 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 13:52 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-09 12:47 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 01:08 +0100
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-09 02:08 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 14:06 +0100
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-09 07:14 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 20:32 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-09 12:42 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 00:30 +0100
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-10 15:01 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:38 +0100
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-10 16:36 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-11 10:43 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 12:59 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-09 03:03 -0800
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-09 12:12 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-09 19:20 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 10:36 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-10 04:27 -0800
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-10 05:13 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-10 06:05 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 15:59 +0100
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-10 15:14 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:45 +0100
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-10 16:02 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 11:45 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-13 12:00 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 12:26 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-13 15:00 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 15:18 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-13 16:00 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 18:43 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 09:26 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 13:30 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 16:16 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 17:49 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 17:14 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 23:05 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-15 08:39 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-15 17:31 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-15 17:11 +0000
Re: "C++ on the Move" by Darryl K. Taft Ben Bacarisse <ben.lists@bsb.me.uk> - 2023-03-15 00:10 +0000
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 14:52 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 20:17 +0100
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 19:31 +0000
Re: "C++ on the Move" by Darryl K. Taft Paavo Helde <eesnimi@osa.pri.ee> - 2023-03-14 00:01 +0200
Re: "C++ on the Move" by Darryl K. Taft gst <g.starck@gmail.com> - 2023-03-13 23:49 -0700
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-14 11:04 +0100
Re: "C++ on the Move" by Darryl K. Taft gst <g.starck@gmail.com> - 2023-03-14 03:26 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 09:08 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 01:21 -0700
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 15:12 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 09:31 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-14 09:51 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 09:56 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-14 10:30 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 13:41 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 14:50 -0700
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 14:13 -0700
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-14 21:53 +0000
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-04 23:21 -0700
Re: "C++ on the Move" by Darryl K. Taft "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-04-05 08:44 -0700
Re: "C++ on the Move" by Darryl K. Taft legalize+jeeves@mail.xmission.com (Richard) - 2023-04-05 15:47 +0000
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-04-05 16:33 +0000
Re: "C++ on the Move" by Darryl K. Taft richardthiebaud <thiebauddick2@aol.com> - 2023-04-05 12:53 -0400
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-04-05 17:19 +0000
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-04-05 13:47 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-04-06 08:12 +0000
Re: "C++ on the Move" by Darryl K. Taft Daniel <danielaparker@gmail.com> - 2023-04-06 05:23 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-04-06 08:09 +0000
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 10:02 -0700
Re: "C++ on the Move" by Darryl K. Taft Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 21:04 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:52 -0700
Re: "C++ on the Move" by Darryl K. Taft Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-20 21:01 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 08:57 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 16:20 +0000
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-10 07:23 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:48 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 15:54 +0100
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-10 07:12 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:53 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-10 08:20 -0800
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-10 16:48 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-12 11:54 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 09:29 -0700
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-12 09:57 -0700
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 10:26 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 14:40 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-13 08:59 -0700
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-12 14:17 -0700
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 16:18 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 14:30 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-13 08:25 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 17:54 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-14 13:27 -0700
Re: "C++ on the Move" by Darryl K. Taft Paavo Helde <eesnimi@osa.pri.ee> - 2023-03-13 20:37 +0200
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-14 13:30 -0700
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-13 10:02 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 20:21 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-13 12:53 -0700
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 01:17 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 09:55 +0100
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-10 16:27 +0000
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-10 11:33 -0800
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-10 11:14 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-11 04:10 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-12 12:06 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 09:29 -0700
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-09 15:26 +0100
Re: "C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-03-09 16:59 -0600
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-10 05:59 +0100
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-10 09:17 +0100
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-10 13:38 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-10 05:10 -0800
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-10 15:20 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:13 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 10:44 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-10 11:08 -0800
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-12 11:42 +0100
Re: "C++ on the Move" by Darryl K. Taft "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-04-06 00:42 -0700
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2023-03-07 15:38 -0600 |
| Subject | "C++ on the Move" by Darryl K. Taft |
| Message-ID | <tu8at1$ijm1$1@dont-email.me> |
"C++ on the Move" by Darryl K. Taft
https://thenewstack.io/c-on-the-move/
"While the C++ programming language seems to be as popular as ever,
efforts to move it forward are ongoing both inside the ISO C++ steering
committee as well as other projects."
Lynn
[toc] | [next] | [standalone]
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2023-03-07 22:08 +0000 |
| Message-ID | <tu8cll$pi8v$1@news.xmission.com> |
| In reply to | #89514 |
[Please do not mail me a copy of your followup]
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
<tu8at1$ijm1$1@dont-email.me> thusly:
>"C++ on the Move" by Darryl K. Taft
A ho-hum article IMO. You've posted better :).
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2023-03-07 16:25 -0600 |
| Message-ID | <tu8dln$j2vi$1@dont-email.me> |
| In reply to | #89515 |
On 3/7/2023 4:08 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
> <tu8at1$ijm1$1@dont-email.me> thusly:
>
>> "C++ on the Move" by Darryl K. Taft
>
> A ho-hum article IMO. You've posted better :).
I was curious in what people thought of the last paragraph, "“Now bring
Rust to the table — a language well-suited for the low-level programming
that C++ typically dominates, but with built-in memory safety and other
modern features,” Campbell said. “When luminaries like Mark Russinovich
are saying things like [‘…halt starting any new projects in C/C++ and
use Rust…’], C++ must evolve or be left behind. The question is, at what
price?” he said."
https://twitter.com/markrussinovich/status/1571995117233504257?lang=en
Thanks,
Lynn
[toc] | [prev] | [next] | [standalone]
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2023-03-07 23:10 +0000 |
| Message-ID | <tu8g94$pjsa$1@news.xmission.com> |
| In reply to | #89517 |
[Please do not mail me a copy of your followup]
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
<tu8dln$j2vi$1@dont-email.me> thusly:
>On 3/7/2023 4:08 PM, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
>> <tu8at1$ijm1$1@dont-email.me> thusly:
>>
>>> "C++ on the Move" by Darryl K. Taft
>>
>> A ho-hum article IMO. You've posted better :).
>
>I was curious in what people thought of the last paragraph, [...]
IMO they found someone with some credibility to say something spicy in
order to get some rage clicks for their article.
That isn't to say that the safety aspects of C++ should be ignored;
but honestly 25 years ago I taught my team the Standard Library
containers and all our memory leaks and crashes disappeared. The
argument that C++ is only as safe as the habits and disciplines of
your team is still true. Herb Sutter's cpp2 is a better way to
address that than Rust, C#, Java, Carbon or whatever new language that
is going to "kill C++" this week.
A weak developer can code resource leaks in any language. I've seen it
done in Java and C# many times by my coworkers. A weak C++ developer
will blame std::vector<> as "buggy" when in reality the types they put
into the container didn't satisfy the Copyable requirement.
Every time some non-C++ programmer complains about how C++ is "unsafe"
and I ask them to show me an example, they show me C code. It's fine
to criticize C++ but at least know what you're talking about when you
do it. If I started bitching about Java and when asked to put up or
shut up, I started showing JavaScript, people would rightly laugh at
me.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-03-08 08:40 +0200 |
| Message-ID | <tu9ali$q8jj$1@dont-email.me> |
| In reply to | #89518 |
08.03.2023 01:10 Richard kirjutas: > [Please do not mail me a copy of your followup] > > Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code > <tu8dln$j2vi$1@dont-email.me> thusly: > >> On 3/7/2023 4:08 PM, Richard wrote: >>> [Please do not mail me a copy of your followup] >>> >>> Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >>> <tu8at1$ijm1$1@dont-email.me> thusly: >>> >>>> "C++ on the Move" by Darryl K. Taft >>> >>> A ho-hum article IMO. You've posted better :). >> >> I was curious in what people thought of the last paragraph, [...] > > IMO they found someone with some credibility to say something spicy in > order to get some rage clicks for their article. > > That isn't to say that the safety aspects of C++ should be ignored; > but honestly 25 years ago I taught my team the Standard Library > containers and all our memory leaks and crashes disappeared. The > argument that C++ is only as safe as the habits and disciplines of > your team is still true. Herb Sutter's cpp2 is a better way to > address that than Rust, C#, Java, Carbon or whatever new language that > is going to "kill C++" this week. > > A weak developer can code resource leaks in any language. I've seen it > done in Java and C# many times by my coworkers. A weak C++ developer > will blame std::vector<> as "buggy" when in reality the types they put > into the container didn't satisfy the Copyable requirement. > > Every time some non-C++ programmer complains about how C++ is "unsafe" > and I ask them to show me an example, they show me C code. It's fine > to criticize C++ but at least know what you're talking about when you > do it. If I started bitching about Java and when asked to put up or > shut up, I started showing JavaScript, people would rightly laugh at > me. +100
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2023-04-05 19:30 -0500 |
| Message-ID | <u0l3re$30p1$1@dont-email.me> |
| In reply to | #89518 |
On 3/7/2023 5:10 PM, Richard wrote: > [Please do not mail me a copy of your followup] > > Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code > <tu8dln$j2vi$1@dont-email.me> thusly: > >> On 3/7/2023 4:08 PM, Richard wrote: >>> [Please do not mail me a copy of your followup] >>> >>> Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >>> <tu8at1$ijm1$1@dont-email.me> thusly: >>> >>>> "C++ on the Move" by Darryl K. Taft >>> >>> A ho-hum article IMO. You've posted better :). >> >> I was curious in what people thought of the last paragraph, [...] > > IMO they found someone with some credibility to say something spicy in > order to get some rage clicks for their article. > > That isn't to say that the safety aspects of C++ should be ignored; > but honestly 25 years ago I taught my team the Standard Library > containers and all our memory leaks and crashes disappeared. The > argument that C++ is only as safe as the habits and disciplines of > your team is still true. Herb Sutter's cpp2 is a better way to > address that than Rust, C#, Java, Carbon or whatever new language that > is going to "kill C++" this week. > > A weak developer can code resource leaks in any language. I've seen it > done in Java and C# many times by my coworkers. A weak C++ developer > will blame std::vector<> as "buggy" when in reality the types they put > into the container didn't satisfy the Copyable requirement. > > Every time some non-C++ programmer complains about how C++ is "unsafe" > and I ask them to show me an example, they show me C code. It's fine > to criticize C++ but at least know what you're talking about when you > do it. If I started bitching about Java and when asked to put up or > shut up, I started showing JavaScript, people would rightly laugh at > me. I agree, the STL solved a bunch of memory problems in C++. Lynn
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-03-07 23:21 -0800 |
| Message-ID | <a77729d8-9fc4-46dc-903d-9a11430ffedbn@googlegroups.com> |
| In reply to | #89517 |
On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: > On 3/7/2023 4:08 PM, Richard wrote: > > [Please do not mail me a copy of your followup] > > > > Lynn McGuire <lynnmc...@gmail.com> spake the secret code > > <tu8at1$ijm1$1...@dont-email.me> thusly: > > > >> "C++ on the Move" by Darryl K. Taft > > > > A ho-hum article IMO. You've posted better :). > > I was curious in what people thought of the last paragraph, "“Now bring > Rust to the table — a language well-suited for the low-level programming > that C++ typically dominates, but with built-in memory safety and other > modern features,” Campbell said. “When luminaries like Mark Russinovich > are saying things like [‘…halt starting any new projects in C/C++ and > use Rust…’], C++ must evolve or be left behind. The question is, at what > price?” he said." > https://twitter.com/markrussinovich/status/1571995117233504257?lang=en > Most people agree that C++ contains too lot of features. They only differ by opinion where to cut. I would put most effort into places where it says "undefined behavior". I think half of such places can be replaced with "program is ill formed", "std::terminate is called" or one of the features that lead to described situation can be cut out (as badly thought thru).
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-03-08 16:10 +0000 |
| Message-ID | <Cr2OL.325072$PXw7.300623@fx45.iad> |
| In reply to | #89520 |
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes: >On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: >> On 3/7/2023 4:08 PM, Richard wrote:=20 >> > [Please do not mail me a copy of your followup]=20 >> >=20 >> > Lynn McGuire <lynnmc...@gmail.com> spake the secret code=20 >> > <tu8at1$ijm1$1...@dont-email.me> thusly:=20 >> >=20 >> >> "C++ on the Move" by Darryl K. Taft=20 >> >=20 >> > A ho-hum article IMO. You've posted better :). >>=20 >> I was curious in what people thought of the last paragraph, "=E2=80=9CNow= > bring=20 >> Rust to the table =E2=80=94 a language well-suited for the low-level prog= >ramming=20 >> that C++ typically dominates, but with built-in memory safety and other= >=20 >> modern features,=E2=80=9D Campbell said. =E2=80=9CWhen luminaries like Ma= >rk Russinovich=20 >> are saying things like [=E2=80=98=E2=80=A6halt starting any new projects = >in C/C++ and=20 >> use Rust=E2=80=A6=E2=80=99], C++ must evolve or be left behind. The quest= >ion is, at what=20 >> price?=E2=80=9D he said."=20 >> https://twitter.com/markrussinovich/status/1571995117233504257?lang=3Den= >=20 >>=20 >Most people agree that C++ contains too lot of features. They only differ >by opinion where to cut. I would put most effort into places where it says= >=20 >"undefined behavior". I think half of such places can be replaced with=20 >"program is ill formed", "std::terminate is called" or one of the features >that lead to described situation can be cut out (as badly thought thru). The nice thing about C++ is that one need not use any of the new crap.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-08 19:47 +0100 |
| Message-ID | <tual8e$11llg$1@dont-email.me> |
| In reply to | #89527 |
On 08/03/2023 17:10, Scott Lurndal wrote: > =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes: >> On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: >>> On 3/7/2023 4:08 PM, Richard wrote:=20 >>>> [Please do not mail me a copy of your followup]=20 >>>> =20 >>>> Lynn McGuire <lynnmc...@gmail.com> spake the secret code=20 >>>> <tu8at1$ijm1$1...@dont-email.me> thusly:=20 >>>> =20 >>>>> "C++ on the Move" by Darryl K. Taft=20 >>>> =20 >>>> A ho-hum article IMO. You've posted better :). >>> =20 >>> I was curious in what people thought of the last paragraph, "=E2=80=9CNow= >> bring=20 >>> Rust to the table =E2=80=94 a language well-suited for the low-level prog= >> ramming=20 >>> that C++ typically dominates, but with built-in memory safety and other= >> =20 >>> modern features,=E2=80=9D Campbell said. =E2=80=9CWhen luminaries like Ma= >> rk Russinovich=20 >>> are saying things like [=E2=80=98=E2=80=A6halt starting any new projects = >> in C/C++ and=20 >>> use Rust=E2=80=A6=E2=80=99], C++ must evolve or be left behind. The quest= >> ion is, at what=20 >>> price?=E2=80=9D he said."=20 >>> https://twitter.com/markrussinovich/status/1571995117233504257?lang=3Den= >> =20 >>> =20 >> Most people agree that C++ contains too lot of features. They only differ >> by opinion where to cut. I would put most effort into places where it says= >> =20 >> "undefined behavior". I think half of such places can be replaced with=20 >> "program is ill formed", "std::terminate is called" or one of the features >> that lead to described situation can be cut out (as badly thought thru). > > The nice thing about C++ is that one need not use any of the new crap. Or one need not use the old crap, and can use the new better features instead. Or a mixture. Or all. Or nearly none. It's a big language, and a big library - few people are going to have use for all of it, but the subset you find useful will vary widely from person to person.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-03-08 11:21 -0800 |
| Message-ID | <ca6d7a7f-2985-4ce0-859a-bc5578b5cfddn@googlegroups.com> |
| In reply to | #89527 |
On Wednesday, March 8, 2023 at 6:10:28 PM UTC+2, Scott Lurndal wrote: > =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> writes: > >On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: > >> On 3/7/2023 4:08 PM, Richard wrote:=20 > >> > [Please do not mail me a copy of your followup]=20 > >> >=20 > >> > Lynn McGuire <lynnmc...@gmail.com> spake the secret code=20 > >> > <tu8at1$ijm1$1...@dont-email.me> thusly:=20 > >> >=20 > >> >> "C++ on the Move" by Darryl K. Taft=20 > >> >=20 > >> > A ho-hum article IMO. You've posted better :). > >>=20 > >> I was curious in what people thought of the last paragraph, "=E2=80=9CNow= > > bring=20 > >> Rust to the table =E2=80=94 a language well-suited for the low-level prog= > >ramming=20 > >> that C++ typically dominates, but with built-in memory safety and other= > >=20 > >> modern features,=E2=80=9D Campbell said. =E2=80=9CWhen luminaries like Ma= > >rk Russinovich=20 > >> are saying things like [=E2=80=98=E2=80=A6halt starting any new projects = > >in C/C++ and=20 > >> use Rust=E2=80=A6=E2=80=99], C++ must evolve or be left behind. The quest= > >ion is, at what=20 > >> price?=E2=80=9D he said."=20 > >> https://twitter.com/markrussinovich/status/1571995117233504257?lang=3Den= > >=20 > >>=20 > >Most people agree that C++ contains too lot of features. They only differ > >by opinion where to cut. I would put most effort into places where it says= > >=20 > >"undefined behavior". I think half of such places can be replaced with=20 > >"program is ill formed", "std::terminate is called" or one of the features > >that lead to described situation can be cut out (as badly thought thru). > The nice thing about C++ is that one need not use any of the new crap. That 's not 100% true. Two example of [not so] new non-crap libraries that are entangled with [not so] new crap - std::chrono and std::random. The former is infected by rational numbers crap. The later is soiled both with <functional> and and with std::ref. And both of them misuse operator overloading. Not that I am aware of many places in standard library where operator overloading is not misused.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-03-08 19:49 +0000 |
| Message-ID | <nF5OL.1052259$Tcw8.731402@fx10.iad> |
| In reply to | #89542 |
Michael S <already5chosen@yahoo.com> writes: >On Wednesday, March 8, 2023 at 6:10:28=E2=80=AFPM UTC+2, Scott Lurndal wrot= >e: >> =3D?UTF-8?B?w5bDtiBUaWli?=3D <oot...@hot.ee> writes:=20 >> >On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: >> >> On 3/7/2023 4:08 PM, Richard wrote:=3D20=20 >> >> > [Please do not mail me a copy of your followup]=3D20=20 >> >> >=3D20=20 >> >> > Lynn McGuire <lynnmc...@gmail.com> spake the secret code=3D20=20 >> >> > <tu8at1$ijm1$1...@dont-email.me> thusly:=3D20=20 >> >> >=3D20=20 >> >> >> "C++ on the Move" by Darryl K. Taft=3D20=20 >> >> >=3D20 >> >> > A ho-hum article IMO. You've posted better :). >> >>=3D20=20 >> >> I was curious in what people thought of the last paragraph, "=3DE2=3D8= >0=3D9CNow=3D=20 >> > bring=3D20=20 >> >> Rust to the table =3DE2=3D80=3D94 a language well-suited for the low-l= >evel prog=3D=20 >> >ramming=3D20=20 >> >> that C++ typically dominates, but with built-in memory safety and othe= >r=3D=20 >> >=3D20=20 >> >> modern features,=3DE2=3D80=3D9D Campbell said. =3DE2=3D80=3D9CWhen lum= >inaries like Ma=3D=20 >> >rk Russinovich=3D20=20 >> >> are saying things like [=3DE2=3D80=3D98=3DE2=3D80=3DA6halt starting an= >y new projects =3D=20 >> >in C/C++ and=3D20=20 >> >> use Rust=3DE2=3D80=3DA6=3DE2=3D80=3D99], C++ must evolve or be left be= >hind. The quest=3D=20 >> >ion is, at what=3D20=20 >> >> price?=3DE2=3D80=3D9D he said."=3D20=20 >> >> https://twitter.com/markrussinovich/status/1571995117233504257?lang=3D= >3Den=3D=20 >> >=3D20=20 >> >>=3D20 >> >Most people agree that C++ contains too lot of features. They only diffe= >r >> >by opinion where to cut. I would put most effort into places where it sa= >ys=3D=20 >> >=3D20=20 >> >"undefined behavior". I think half of such places can be replaced with= >=3D20 >> >"program is ill formed", "std::terminate is called" or one of the featur= >es=20 >> >that lead to described situation can be cut out (as badly thought thru). >> The nice thing about C++ is that one need not use any of the new crap. > >That 's not 100% true. >Two example of [not so] new non-crap libraries that are entangled with [not= > so] new >crap - std::chrono and std::random. There are platform native interfaces providing the functionality of both std::chrono and std::random, so yes, it's true.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-03-08 12:08 -0800 |
| Message-ID | <4857b7e6-6a7b-4719-b681-2a233dfa450an@googlegroups.com> |
| In reply to | #89544 |
On Wednesday, March 8, 2023 at 9:49:54 PM UTC+2, Scott Lurndal wrote: > Michael S <already...@yahoo.com> writes: > >On Wednesday, March 8, 2023 at 6:10:28=E2=80=AFPM UTC+2, Scott Lurndal wrot= > >e: > >> =3D?UTF-8?B?w5bDtiBUaWli?=3D <oot...@hot.ee> writes:=20 > >> >On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: > >> >> On 3/7/2023 4:08 PM, Richard wrote:=3D20=20 > >> >> > [Please do not mail me a copy of your followup]=3D20=20 > >> >> >=3D20=20 > >> >> > Lynn McGuire <lynnmc...@gmail.com> spake the secret code=3D20=20 > >> >> > <tu8at1$ijm1$1...@dont-email.me> thusly:=3D20=20 > >> >> >=3D20=20 > >> >> >> "C++ on the Move" by Darryl K. Taft=3D20=20 > >> >> >=3D20 > >> >> > A ho-hum article IMO. You've posted better :). > >> >>=3D20=20 > >> >> I was curious in what people thought of the last paragraph, "=3DE2=3D8= > >0=3D9CNow=3D=20 > >> > bring=3D20=20 > >> >> Rust to the table =3DE2=3D80=3D94 a language well-suited for the low-l= > >evel prog=3D=20 > >> >ramming=3D20=20 > >> >> that C++ typically dominates, but with built-in memory safety and othe= > >r=3D=20 > >> >=3D20=20 > >> >> modern features,=3DE2=3D80=3D9D Campbell said. =3DE2=3D80=3D9CWhen lum= > >inaries like Ma=3D=20 > >> >rk Russinovich=3D20=20 > >> >> are saying things like [=3DE2=3D80=3D98=3DE2=3D80=3DA6halt starting an= > >y new projects =3D=20 > >> >in C/C++ and=3D20=20 > >> >> use Rust=3DE2=3D80=3DA6=3DE2=3D80=3D99], C++ must evolve or be left be= > >hind. The quest=3D=20 > >> >ion is, at what=3D20=20 > >> >> price?=3DE2=3D80=3D9D he said."=3D20=20 > >> >> https://twitter.com/markrussinovich/status/1571995117233504257?lang=3D= > >3Den=3D=20 > >> >=3D20=20 > >> >>=3D20 > >> >Most people agree that C++ contains too lot of features. They only diffe= > >r > >> >by opinion where to cut. I would put most effort into places where it sa= > >ys=3D=20 > >> >=3D20=20 > >> >"undefined behavior". I think half of such places can be replaced with= > >=3D20 > >> >"program is ill formed", "std::terminate is called" or one of the featur= > >es=20 > >> >that lead to described situation can be cut out (as badly thought thru). > >> The nice thing about C++ is that one need not use any of the new crap. > > > >That 's not 100% true. > >Two example of [not so] new non-crap libraries that are entangled with [not= > > so] new > >crap - std::chrono and std::random. > There are platform native interfaces providing the functionality of both > std::chrono and std::random, so yes, it's true. The whole point of std::chrono and std:random is that they are cross-platform. May be, you don't care for anything non-Linux, but I certainly do.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-08 09:52 -0800 |
| Message-ID | <87pm9jqgeh.fsf@nosuchdomain.example.com> |
| In reply to | #89520 |
Öö Tiib <ootiib@hot.ee> writes:
> On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote:
>> On 3/7/2023 4:08 PM, Richard wrote:
>> > [Please do not mail me a copy of your followup]
>> >
>> > Lynn McGuire <lynnmc...@gmail.com> spake the secret code
>> > <tu8at1$ijm1$1...@dont-email.me> thusly:
>> >
>> >> "C++ on the Move" by Darryl K. Taft
>> >
>> > A ho-hum article IMO. You've posted better :).
>>
>> I was curious in what people thought of the last paragraph, "“Now bring
>> Rust to the table — a language well-suited for the low-level programming
>> that C++ typically dominates, but with built-in memory safety and other
>> modern features,” Campbell said. “When luminaries like Mark Russinovich
>> are saying things like [‘…halt starting any new projects in C/C++ and
>> use Rust…’], C++ must evolve or be left behind. The question is, at what
>> price?” he said."
>> https://twitter.com/markrussinovich/status/1571995117233504257?lang=en
>>
> Most people agree that C++ contains too lot of features. They only differ
> by opinion where to cut. I would put most effort into places where it says
> "undefined behavior". I think half of such places can be replaced with
> "program is ill formed", "std::terminate is called" or one of the features
> that lead to described situation can be cut out (as badly thought thru).
I'd be interested in seeing some cases of undefined behavior that could
reasonably be detected at compile time or at run time. I'm sure there
are some, but I'd be surprised it were as many as half.
Just one example: Signed integer overflow has undefined behavior, and
defining it would require runtime checks.
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-03-08 10:18 -0800 |
| Message-ID | <64eba816-6723-4012-bad5-d59c457ba8e8n@googlegroups.com> |
| In reply to | #89535 |
On Wednesday, 8 March 2023 at 17:53:09 UTC, Keith Thompson wrote: > Öö Tiib <oot...@hot.ee> writes: > > On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: > >> On 3/7/2023 4:08 PM, Richard wrote: > >> > [Please do not mail me a copy of your followup] > >> > > >> > Lynn McGuire <lynnmc...@gmail.com> spake the secret code > >> > <tu8at1$ijm1$1...@dont-email.me> thusly: > >> > > >> >> "C++ on the Move" by Darryl K. Taft > >> > > >> > A ho-hum article IMO. You've posted better :). > >> > >> I was curious in what people thought of the last paragraph, "“Now bring > >> Rust to the table — a language well-suited for the low-level programming > >> that C++ typically dominates, but with built-in memory safety and other > >> modern features,” Campbell said. “When luminaries like Mark Russinovich > >> are saying things like [‘…halt starting any new projects in C/C++ and > >> use Rust…’], C++ must evolve or be left behind. The question is, at what > >> price?” he said." > >> https://twitter.com/markrussinovich/status/1571995117233504257?lang=en > >> > > Most people agree that C++ contains too lot of features. They only differ > > by opinion where to cut. I would put most effort into places where it says > > "undefined behavior". I think half of such places can be replaced with > > "program is ill formed", "std::terminate is called" or one of the features > > that lead to described situation can be cut out (as badly thought thru). > I'd be interested in seeing some cases of undefined behavior that could > reasonably be detected at compile time or at run time. I'm sure there > are some, but I'd be surprised it were as many as half. > > Just one example: Signed integer overflow has undefined behavior, and > defining it would require runtime checks. > Not on the vast majority of platforms. However you'd have to define the behaviour as a two's complement wrap.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-08 20:45 +0100 |
| Message-ID | <tuaolf$12cim$1@dont-email.me> |
| In reply to | #89536 |
On 08/03/2023 19:18, Malcolm McLean wrote: > On Wednesday, 8 March 2023 at 17:53:09 UTC, Keith Thompson wrote: >> Öö Tiib <oot...@hot.ee> writes: >>> On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: >>>> On 3/7/2023 4:08 PM, Richard wrote: >>>>> [Please do not mail me a copy of your followup] >>>>> >>>>> Lynn McGuire <lynnmc...@gmail.com> spake the secret code >>>>> <tu8at1$ijm1$1...@dont-email.me> thusly: >>>>> >>>>>> "C++ on the Move" by Darryl K. Taft >>>>> >>>>> A ho-hum article IMO. You've posted better :). >>>> >>>> I was curious in what people thought of the last paragraph, "“Now bring >>>> Rust to the table — a language well-suited for the low-level programming >>>> that C++ typically dominates, but with built-in memory safety and other >>>> modern features,” Campbell said. “When luminaries like Mark Russinovich >>>> are saying things like [‘…halt starting any new projects in C/C++ and >>>> use Rust…’], C++ must evolve or be left behind. The question is, at what >>>> price?” he said." >>>> https://twitter.com/markrussinovich/status/1571995117233504257?lang=en >>>> >>> Most people agree that C++ contains too lot of features. They only differ >>> by opinion where to cut. I would put most effort into places where it says >>> "undefined behavior". I think half of such places can be replaced with >>> "program is ill formed", "std::terminate is called" or one of the features >>> that lead to described situation can be cut out (as badly thought thru). >> I'd be interested in seeing some cases of undefined behavior that could >> reasonably be detected at compile time or at run time. I'm sure there >> are some, but I'd be surprised it were as many as half. >> >> Just one example: Signed integer overflow has undefined behavior, and >> defining it would require runtime checks. >> > Not on the vast majority of platforms. However you'd have to define the > behaviour as a two's complement wrap. > Wrapping is not the only option. But since wrapping is the most useless behaviour for signed integer overflow, doing something helpful (such as the suggested call to std::terminate, or other error message to aid debugging) /would/ require run-time checks.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2023-03-08 19:20 +0100 |
| Message-ID | <tuajln$11eec$1@dont-email.me> |
| In reply to | #89535 |
On 2023-03-08 6:52 PM, Keith Thompson wrote: > Öö Tiib <ootiib@hot.ee> writes: >> On Wednesday, 8 March 2023 at 00:26:14 UTC+2, Lynn McGuire wrote: >>> On 3/7/2023 4:08 PM, Richard wrote: >>>> [Please do not mail me a copy of your followup] >>>> >>>> Lynn McGuire <lynnmc...@gmail.com> spake the secret code >>>> <tu8at1$ijm1$1...@dont-email.me> thusly: >>>> >>>>> "C++ on the Move" by Darryl K. Taft >>>> >>>> A ho-hum article IMO. You've posted better :). >>> >>> I was curious in what people thought of the last paragraph, "“Now bring >>> Rust to the table — a language well-suited for the low-level programming >>> that C++ typically dominates, but with built-in memory safety and other >>> modern features,” Campbell said. “When luminaries like Mark Russinovich >>> are saying things like [‘…halt starting any new projects in C/C++ and >>> use Rust…’], C++ must evolve or be left behind. The question is, at what >>> price?” he said." >>> https://twitter.com/markrussinovich/status/1571995117233504257?lang=en >>> >> Most people agree that C++ contains too lot of features. They only differ >> by opinion where to cut. I would put most effort into places where it says >> "undefined behavior". I think half of such places can be replaced with >> "program is ill formed", "std::terminate is called" or one of the features >> that lead to described situation can be cut out (as badly thought thru). > > I'd be interested in seeing some cases of undefined behavior that could > reasonably be detected at compile time or at run time. I'm sure there > are some, but I'd be surprised it were as many as half. > > Just one example: Signed integer overflow has undefined behavior, and > defining it would require runtime checks. I guess you meant to write, "detecting it", not "defining it". Defining signed overflow as wrap-around requires no runtime checks, now that C++ integers are guaranteed two's complement. Some optimization opportunities would be lost, but maybe others gained. - Alf
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-03-08 14:10 -0500 |
| Message-ID | <tuamjh$11oqn$1@dont-email.me> |
| In reply to | #89537 |
On 3/8/23 13:20, Alf P. Steinbach wrote: > On 2023-03-08 6:52 PM, Keith Thompson wrote: ... >> I'd be interested in seeing some cases of undefined behavior that could >> reasonably be detected at compile time or at run time. I'm sure there >> are some, but I'd be surprised it were as many as half. >> >> Just one example: Signed integer overflow has undefined behavior, and >> defining it would require runtime checks. > > I guess you meant to write, "detecting it", not "defining it". No, he meant "defining it". If they were to choose to define the behavior of signed integer overflow, then on platforms where the defined behavior was not the same as that which would naturally occur, run-time checks would be required to change the behavior.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2023-03-08 22:34 +0100 |
| Message-ID | <tuav0b$13dk4$1@dont-email.me> |
| In reply to | #89541 |
On 2023-03-08 8:10 PM, James Kuyper wrote: > On 3/8/23 13:20, Alf P. Steinbach wrote: >> On 2023-03-08 6:52 PM, Keith Thompson wrote: > ... >>> I'd be interested in seeing some cases of undefined behavior that could >>> reasonably be detected at compile time or at run time. I'm sure there >>> are some, but I'd be surprised it were as many as half. >>> >>> Just one example: Signed integer overflow has undefined behavior, and >>> defining it would require runtime checks. >> >> I guess you meant to write, "detecting it", not "defining it". > > No, he meant "defining it". If they were to choose to define the > behavior of signed integer overflow, then on platforms where the defined > behavior was not the same as that which would naturally occur, run-time > checks would be required to change the behavior. Can you give a concrete (even if hypothetical) example of what you mean? - Alf
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-08 14:29 -0800 |
| Message-ID | <87cz5iri6g.fsf@nosuchdomain.example.com> |
| In reply to | #89550 |
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> On 2023-03-08 8:10 PM, James Kuyper wrote:
>> On 3/8/23 13:20, Alf P. Steinbach wrote:
>>> On 2023-03-08 6:52 PM, Keith Thompson wrote:
>> ...
>>>> I'd be interested in seeing some cases of undefined behavior that could
>>>> reasonably be detected at compile time or at run time. I'm sure there
>>>> are some, but I'd be surprised it were as many as half.
>>>>
>>>> Just one example: Signed integer overflow has undefined behavior, and
>>>> defining it would require runtime checks.
>>>
>>> I guess you meant to write, "detecting it", not "defining it".
>> No, he meant "defining it". If they were to choose to define the
>> behavior of signed integer overflow, then on platforms where the defined
>> behavior was not the same as that which would naturally occur, run-time
>> checks would be required to change the behavior.
>
> Can you give a concrete (even if hypothetical) example of what you mean?
For example, a future C++ standard might specify that signed integer
overflow throws a language-defined exception, or it might require
saturation (so INT_MAX + 1 == INT_MAX). If the target hardware
doesn't support that in some way, then checks have to be added.
If the standard defined signed integer overflow as two's-complement
wraparound (INT_MAX + 1 == INT_MIN), additional checks would not be
required on most target systems (perhaps all current ones). I didn't
have that specific definition in mind.
Or it might define out-of-bounds array indexing (for plain C-like
arrays) to wrap around, so that given `int a[10];` the expression
`a[15]` or `a[-5]` would be equivalent to `a[5]`. Or it could
require an exception to be thrown.
Ada defines signed integer overflow and out-of-bounds indexing to
raise an exception, so there is precedent. Both require the compiler
to insert run-time checks, which can be removed during optimization
if the compiler can prove that the error will never occur. And there
are mechanisms to suppress the checks; if an exception would have
been raised but the check is suppressed, the behavior is undefined
(Ada calls it "erroneous execution").
Again, I didn't intend to concentrate on the case of signed integer
overflow. My question was about which cases of undefined behavior
could be made into defined behavior without adding runtime checks.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-09 00:59 +0100 |
| Message-ID | <tub7gl$14r60$1@dont-email.me> |
| In reply to | #89552 |
On 08/03/2023 23:29, Keith Thompson wrote: > "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes: >> On 2023-03-08 8:10 PM, James Kuyper wrote: >>> On 3/8/23 13:20, Alf P. Steinbach wrote: >>>> On 2023-03-08 6:52 PM, Keith Thompson wrote: >>> ... >>>>> I'd be interested in seeing some cases of undefined behavior that could >>>>> reasonably be detected at compile time or at run time. I'm sure there >>>>> are some, but I'd be surprised it were as many as half. >>>>> >>>>> Just one example: Signed integer overflow has undefined behavior, and >>>>> defining it would require runtime checks. >>>> >>>> I guess you meant to write, "detecting it", not "defining it". >>> No, he meant "defining it". If they were to choose to define the >>> behavior of signed integer overflow, then on platforms where the defined >>> behavior was not the same as that which would naturally occur, run-time >>> checks would be required to change the behavior. >> >> Can you give a concrete (even if hypothetical) example of what you mean? > > For example, a future C++ standard might specify that signed integer > overflow throws a language-defined exception, or it might require > saturation (so INT_MAX + 1 == INT_MAX). If the target hardware > doesn't support that in some way, then checks have to be added. > > If the standard defined signed integer overflow as two's-complement > wraparound (INT_MAX + 1 == INT_MIN), additional checks would not be > required on most target systems (perhaps all current ones). I didn't > have that specific definition in mind. > > Or it might define out-of-bounds array indexing (for plain C-like > arrays) to wrap around, so that given `int a[10];` the expression > `a[15]` or `a[-5]` would be equivalent to `a[5]`. Or it could > require an exception to be thrown. > > Ada defines signed integer overflow and out-of-bounds indexing to > raise an exception, so there is precedent. Both require the compiler > to insert run-time checks, which can be removed during optimization > if the compiler can prove that the error will never occur. And there > are mechanisms to suppress the checks; if an exception would have > been raised but the check is suppressed, the behavior is undefined > (Ada calls it "erroneous execution"). > > Again, I didn't intend to concentrate on the case of signed integer > overflow. My question was about which cases of undefined behavior > could be made into defined behavior without adding runtime checks. > It is also perhaps worth noting that if signed integer overflow is left undefined, some optimisations are possible for the compiler that are not if overflow is required to be wrapping. That might not qualify as "run-time checks", but it is certainly "run-time overhead" in comparison to the current language definition.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web