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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-03-14 13:27 -0700 |
| Message-ID | <ce07db31-faea-4510-b103-77008b7bbeaen@googlegroups.com> |
| In reply to | #89717 |
On Monday, 13 March 2023 at 18:54:47 UTC+2, David Brown wrote: > On 13/03/2023 16:25, Öö Tiib wrote: > > It is becoming relatively rarely worth to write C++ for PC. Small > > processors tend to be quite powerful for surrounding hardware so > > are often idle. If these have some algebra to do then it is often floating > > point or if these compress, decompress or crypt something then that > > is done with wrapping arithmetic. In my experience. You might have > > different problem domain. > > > The work done on PC's is totally and completely dominated by code > written in C or C++. You will probably find that all but a couple of > percent of used processor cycles is running code written in C or C++. > The programmer may have written source code in C#, or Python, or Ruby, > but the VM it runs on is in C or C++. The libraries that do the work in > the graphics, the network, the filesystems, the game engine - it's all C > and C++. > Fundamental blocks of lot of platforms are written in C or C++ with bit of assembler. Apple has done lot of it in Objective-C. Rest like Fortran, Ada, Rust, Go, Erlang, Haskell, Lisp matter only narrowly/locally. But consider what I use right now? Google groups. Aggravating garbage but works on any device under hand that does *not* have something better to do at the moment. > I think it is a good thing that people use different languages on PC's. > People can find a different balance between efficiency of the developer > and efficiency at run-time, or between developer knowledge and > experience and the safety of the code. Some will use low-level > languages and take care to get the details right - others will use > high-level languages and let the language runtime handle the details. > > But you could say that it is precisely because a lot of modern PC > programming is done in languages other than C and C++, that it is even > more important that efficiency is a high-priority in C and C++. And it > is even more appropriate to expect the C and C++ programmers to be good > at their jobs and not need hand-holding to get simple tasks right. > Shareholders of product do not think like that ... for them to have cheaper, faster and more reliable maintenance team is higher priority. Otherwise there will be syndrome of "legacy that may not be touched" and good products simply degrade and die because of upkeep being too expensive. > So for PC's, you absolutely want to be able to conduct your integer > arithmetic as fast as possible without any unnecessary checking, traps, > exceptions, or other hinders in the flow. > I don't want as rule. It is maybe in 5% of code base where micro-optimizations may give few percents of advantage and there I expect every trick to be commented with performance issue ID. I do reject removal of #ifdef NDEBUG #error "defining NDEBUG without author's permission not allowed" #endif from my code. And I would like that language supported me there with attributes or keywords like "unsafe". > As for your comments on embedded systems, I think you are seriously > misunderstanding the point when you say it is often wrapping arithmetic. > If wrapping is what you need - and it is /sometimes/ right, but not > often, even in cryptography - that's fine. But if it is wrong, it is > wrong. It really doesn't matter here if the behaviour is defined and > wrong, or undefined and wrong - except that being defined means it's > harder to find the errors and efficiency might be lower. The programmer > still needs to make the effort to make sure the inputs are valid for the > expressions in use. And when the programmer has made the effort, any > extra checks added by the compiler are a waste. > You perhaps misunderstood yourself. I meant that cryptography, hashing, compression are done with unsigned arithmetic that is required to be wrapping and calculations of physical values with floating point that is required to be saturating. Can you bring examples of costly signed integer arithmetic processing that is needed in embedded context? > (I would like C and C++ to have unsigned types that have undefined > overflow behaviour, as found in the language Zig. I would not want to > give up on having wrapping types too - I want both.) > I have throwing fixed range integers (from 0 to anything and from anything to anything) and simple containers of those. > > Pointer arithmetic is also not signed integer arithmetic. So signed > > integer undefined behaviors do not help with those cases. > > > Pointer arithmetic is calculated with integer arithmetic semantics in C > and C++, and with the same kind of instructions in implementations. But > it has even more restrictions in the valid domains and it is even harder > to detect overflows. "arr[i]" means "*(arr + i)", where the expression > "arr + i" overflows on any result outside the array. Everything that > applies to signed integer overflow applies even more so to pointer > arithmetic. > But it is way different, nearing to my integers from anything to anything. I do not even dream of adding that to standard (or even boost) without hardware support. > > Great that you agree. Note that it does not run inefficiently. There are > > not lot of "magic" performance boosts hidden in unreliability of signed > > integers. Rust for example traps in debug mode and wraps in release > > mode ... result is rather competitive in performance. Ada always throws > > and also performs not bad. > > > Rust and Ada perform reasonably, but not on a par with C and C++. > People spend vast amounts on buying a processor that is 20% faster than > mainstream alternatives - they do not want to run their code 50% slower. > 50% slower are Java and C#. That is what one pays for too lot of indirection and runtime reflection. Can't repair those choices with JIT. About Ada I have too few information to argue, I dislike its syntax and one should not use disliked tools by my world view. Rust runs generally exactly as well as C or C++. Often with none of "unsafe" blocks. It compiles slower and competent workforce is harder to find. What Rust lacks are fixed-size arrays and SIMD support for floating point then it could fly past C++ in scientific computing. Some constexpr/consteval support would also help Rust. Not its performance but to reason. No need to go as far as C++ has gone but it is sometimes annoying to prepare constant data like in C on meta level or with generator tools. > Your thoughts here seems to be based on the idea that code just does a > bit of integer arithmetic every now and again, and the cpu is probably > waiting for slow main memory anyway. That's true for some code. It is > very far from true for other code. > You never give examples of that mysterious processing I haven't met. > On small systems, you are rarely waiting for memory, and individual > cycles count. You don't enable exceptions in C++, you don't stop with > error messages - you have nowhere to show an error message. Even if you > do get an error, what are you going to do about it? Recall all the > microwave ovens or oil valve controllers you've made? You write the > code correctly so that it doesn't overflow, and doesn't stop - or you > are looking for a new job. Extra checking just means bigger and more > expensive hardware to do the same job, taking extra power from your > battery life. > What signed integer arithmetic does a valve controller or a microwave oven do in performance altering quantities? But of course there are special safety processors for panic situations where it matters like in industrial automatics, lifts, cranes and such. Does not matter what bug it is those can't "full stop" electric motors without spectacular outcome. On the other hand if it is opposite with controller of some kind of ventilation system. That has mode "try to keep system ventilating even when you can prove that you are literally melting". > And if you look at PC's and big processors, you might have noticed a > trend in the last decades of more and more vector processing. While > some of that is for floating point vectors, doesn't it still give you a > clue that people /do/ care about integer arithmetic performance? > Nope. I have no idea. Market is empty of video cards but again nothing I know of is crunching undefined behavior signed integers on those. > > Yes, I have helped to repair overflow bugs from such classes. These > > work OK. > > That's the great thing about C++. Get it working right once, and use it > repeatedly. > Yes, reusability is indeed amazing. Noteworthy platform vendors can massively bad mouth but never take any actions to fight with C++. > > I hope that quite soon. One day they should end adding (sub-bar > > for my usages) stuff like <valarray>, <regex> or <format>. > > > Different people have different needs. There's lots in the standard > library that is useless to me - but I realise it is useful to /some/ people. > I do not argue ... I just know none of them, but plenty of those who use likes of __builtin_add_overflow, that <stdckdint.h> finally adds. > > It is unclear to me why it must be default behavior. For me most > > optimizations are worth to do only in small subset of code base. > > And there other things like reducing copying, dynamic allocations or > > adding cache blocking give way more than signed integer > > micro-optimizations. Especially if those are compared to wrapping > > (that I agree is usually error). Explicit checks and branches in code > > can cost now but I'm sure that if like's of Ada and Rust gain more > > market then hardware guys will add trapping signed integers. > > > Just to be clear here - gcc (and presumably other compilers) have had > options for defined signed integer overflow for decades. You can choose > wrapping (-fwrapv) or trapping (-ftrapv). These are very rarely used in > practice - people either don't know about such things (and those > programmers would be unlikely to do a decent job of handling run-time > errors even if were the default), or they don't want such features. > I know. Over half of stackoverflow questions are from them ... I compiled it without reading warnings nor errors and "it doesn't work", can anyone help me? But they are not yet on level of producing anything that matters. > gcc > developers have long since realised that trying to make relatively > efficient checked integer arithmetic (as -ftrapv did) was pretty much > useless. It had significant overhead, was inconsistent, gave little > useful feedback, and only handled one small class of common errors. Exactly. That is why I say better remove quarter of whatever undefined beaviors ... as philosophy, take any however unimportant, not one odd-ball like signed integer overflow. > Instead, they recommend more complete debugging tools such as sanitizers > that check much more and give more useful debugging feedback. > But I do not see it as debugging tool. I see it as way for mad process to die quicker so reserve/backup can take over faster. Vector has its at() ... so could have signed integers. > Ada is virtually dead as a language. Rust is a fad - the benefits you > get from re-writing C code in Rust can be achieved almost entirely by > re-writing the C code in decent modern C and using modern C development > tools. (Still, if it is easier to make people fix bugs by re-writing in > Rust than getting them to re-write in good C, the end result is fewer > bugs.) And if your re-write is good modern C++, even better. Why > bother with code analysis "borrow checker" tools with Rust when you can > write the code in C++ in a way that makes you sure you don't have memory > usage failures? I suppose the best you can say is that Rust makes it > marginally harder to write incorrect code, for some kinds of error. > It is impossible to produce general purpose language in what nonsense, bullshit or lie can't be expressed. Only illusions and typos can be limited. Rust does it rather well, Swift does it less well but more beautifully and tersely. > > Rust attempts to do that and in quite convincing manner. It is bit raw > > yet and so tricky to populate a team but it gets better all the time. > > > You've swallowed the cool-aid. Rust, with all its bells and whistles > used correctly, is a big step up from malloc/free, and even new/delete. > But if you are happy with the overhead then you can replace you arrays > with std::vector and you don't need a half-made borrow checker to be > sure you are leak-free. > Rust is about reducing whole classes of common bugs. Yes like RAII reduces resource leaks. Note that not removal but reduction is key there. RAII indeed works wonders already in C++. > >> That is why it is vital that such mistakes in code are undefined > >> behaviour - because only then can tools add testing and trapping > >> behaviour to aid debugging. > > > > That does not follow. Defined error helps to debug lot better, as it > > is required to fail compile or run time and so can be silenced only > > with special options not achieved by using separate special tools. > > I can only re-state my points in a limited number of ways. Either you > understand what I am saying, or you don't. > Perhaps without examples we are stuck indeed.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-03-13 20:37 +0200 |
| Message-ID | <tunqi6$3so24$1@dont-email.me> |
| In reply to | #89712 |
13.03.2023 17:25 Öö Tiib kirjutas: > It is becoming relatively rarely worth to write C++ for PC. This might be so, but when something deliberately gets written in C++ on PC then this is most often done to squeeze out the maximum performance. Slowing down the program by e.g. mandatory signed integer overflow checks would be a big no-no. There is a reason why C and C++ adhere to the zero overhead principle. If I know or have verified that no overflow can occur in my vector arithmetics, I should not pay any penalty during the operation.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-03-14 13:30 -0700 |
| Message-ID | <66840bf0-b9cd-4d8d-a2ca-5e2a14cc1dc7n@googlegroups.com> |
| In reply to | #89719 |
On Monday, 13 March 2023 at 20:38:16 UTC+2, Paavo Helde wrote: > 13.03.2023 17:25 Öö Tiib kirjutas: > > > It is becoming relatively rarely worth to write C++ for PC. > This might be so, but when something deliberately gets written in C++ on > PC then this is most often done to squeeze out the maximum performance. > Slowing down the program by e.g. mandatory signed integer overflow > checks would be a big no-no. > > There is a reason why C and C++ adhere to the zero overhead principle. > If I know or have verified that no overflow can occur in my vector > arithmetics, I should not pay any penalty during the operation. > Compiler can prove it and remove the checks as well. I trust it is matter of years not decades when we reach that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-13 10:02 -0700 |
| Message-ID | <87bkkwpotb.fsf@nosuchdomain.example.com> |
| In reply to | #89708 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> We've already gone through this. Nothing good can ever come of trying
> to execute something with undefined behaviour.
That's not entirely true. Extensions (which are explicitly permitted by
the standard) can take the form of an implementation defining behavior
that is not defined by the standard.
--
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-13 20:21 +0100 |
| Message-ID | <tunt36$3t5ek$2@dont-email.me> |
| In reply to | #89718 |
On 13/03/2023 18:02, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> We've already gone through this. Nothing good can ever come of trying >> to execute something with undefined behaviour. > > That's not entirely true. Extensions (which are explicitly permitted by > the standard) can take the form of an implementation defining behavior > that is not defined by the standard. > I was using the term "undefined behaviour" here to mean behaviour that is not defined by the standards, the implementation, or any other relevant specification. It's fine to use things that are defined only in a particular implementation - although of course the result is not portable. (For example, with "gcc -fwrapv", signed integer overflow is fully defined.) I could have been clearer about that in my post, however.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-13 12:53 -0700 |
| Message-ID | <877cvkpgvr.fsf@nosuchdomain.example.com> |
| In reply to | #89724 |
David Brown <david.brown@hesbynett.no> writes:
> On 13/03/2023 18:02, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> We've already gone through this. Nothing good can ever come of trying
>>> to execute something with undefined behaviour.
>> That's not entirely true. Extensions (which are explicitly
>> permitted by
>> the standard) can take the form of an implementation defining behavior
>> that is not defined by the standard.
>
> I was using the term "undefined behaviour" here to mean behaviour that
> is not defined by the standards, the implementation, or any other
> relevant specification. It's fine to use things that are defined only
> in a particular implementation - although of course the result is not
> portable. (For example, with "gcc -fwrapv", signed integer overflow
> is fully defined.)
>
> I could have been clearer about that in my post, however.
The standard defines "undefined behavior" as "behavior for which this
document [the standard] imposes no requirements". I recommend not using
that particular phrase with a different meaning.
Certainly relying on behavior that isn't defined either by the standard,
by any applicable secondary standard, or by the implementation is a bad
idea.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-14 01:17 -0700 |
| Message-ID | <86a60f9278.fsf@linuxsc.com> |
| In reply to | #89727 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > The standard defines "undefined behavior" as "behavior for which > this document [the standard] imposes no requirements". I recommend > not using that particular phrase with a different meaning. Wholeheartedly agree. A lot of people think "undefined behavior" is synonymous with "might behave in an unpredictable fashion". That supposed equivalence is simply wrong, and there should never be any ambiguity about its wrongness.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-14 09:55 +0100 |
| Message-ID | <tupcpq$8p9i$1@dont-email.me> |
| In reply to | #89727 |
On 13/03/2023 20:53, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 13/03/2023 18:02, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> We've already gone through this. Nothing good can ever come of trying >>>> to execute something with undefined behaviour. >>> That's not entirely true. Extensions (which are explicitly >>> permitted by >>> the standard) can take the form of an implementation defining behavior >>> that is not defined by the standard. >> >> I was using the term "undefined behaviour" here to mean behaviour that >> is not defined by the standards, the implementation, or any other >> relevant specification. It's fine to use things that are defined only >> in a particular implementation - although of course the result is not >> portable. (For example, with "gcc -fwrapv", signed integer overflow >> is fully defined.) >> >> I could have been clearer about that in my post, however. > > The standard defines "undefined behavior" as "behavior for which this > document [the standard] imposes no requirements". I recommend not using > that particular phrase with a different meaning. > I had thought my meaning was clear, but you are absolutely right to recommend being more precise here. There's been a certain amount of misunderstanding and miscommunication in this thread already - I should not make it worse by lazy wording! > Certainly relying on behavior that isn't defined either by the standard, > by any applicable secondary standard, or by the implementation is a bad > idea. >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-03-10 16:27 +0000 |
| Message-ID | <oTIOL.163906$0XR7.94809@fx07.iad> |
| In reply to | #89626 |
David Brown <david.brown@hesbynett.no> writes: >On 10/03/2023 13:27, Öö Tiib wrote: >> On Friday, 10 March 2023 at 11:36:26 UTC+2, David Brown wrote: >>> On 10/03/2023 04:20, Öö Tiib wrote: >>> >>>> It is all about the trend. Most platforms trap on division by zero for >>>> very long time. Yet the standards declare that they define nothing. >>> No, most platforms do not trap on division by zero. >>> >>> The solid majority of different types of platforms that are programmed >>> in C (and C++ gets this stuff from C) are small microcontrollers and >>> other embedded processors. >>> >>> The solid majority of processor cores made and sold are small >>> microcontrollers. >>> >> Their reasoning of hardware designers is such: "division by 0 is undefined >> anyway and so we counted that setting all bits of result to 1 takes few less >> internal gates than setting all bits to 0 does." >> So the whole reason of such design is lack of market to trap on division >> by zero there. > >Are you basing this on your intimate knowledge of the design decisions >made by multiple cpu design teams? > >Everyone who has made it through primary school knows it makes no sense >to divide by zero. It therefore makes no sense for a processor to aim >for any particular result when someone tries to do the impossible. If a >processor already has strong support for hardware exceptions as a >debugging aid and for safe handling of multiple independent programs (as >you get on a "big" general purpose cpu), then it is likely to have a >trap of some sort on division by zero. If it is a chip optimised for >low cost, size or power, for dedicated single-program microcontroller >usage, then division by zero can be a "don't care". It might cause a >reset, a hang, a nonsense result, a consistent and documented result - >whatever. Here's what one of the Burroughs mainframes did with DIV: ==== Function ==== The Divide instruction divides the contents of one memory location **B** by the contents of a second memory location **A** storing the remainder in the **B** data field and storing the quotient in a third memory location **C**. The length of the __dividend__ field must be greater than the length of the __divisor__ field (**BF** greater than **AF**). The length of the __quotient__ field is the difference in length of the **A** and **B** fields (**BF** - **AF**). If the result is too large to fit into the __quotient__ field or if **BF** is not greater than **AF**, the division is not performed, the contents of **B** and **C** are unchanged, the [[processor_state:comparison_flags|Comparison Flags]] are unchanged and the [[processor_state:overflow_flag|Overflow Flag]] is set. If the absolute value of the __divisor__ is not greater than the absolute value of the equivalent number of leading digits of the __dividend__, the division is not performed and the [[processor_state:overflow_flag|Overflow Flag]] is set with the [[processor_state:comparison_flags|Comparison Flags]] remaining unchanged. Note that a __divisor__ which is zero will fail this test and the [[processor_state:overflow_flag|Overflow Flag]] will be set. Store the absolute value of the quotient when the __quotient__ field data type is unsigned (**UN** or **UA**). Store the standard **EBCDIC** form of the result sign as the first digit of the result when the __quotient__ field data type is **SN**. Fill the zone digit with the **EBCDIC** numeric subset code (**F**) when the __quotient__ field data type is alphanumeric (**UA**). Store the absolute value of the remainder when the __remainder__ field data type is unsigned (**UN** or **UA**). Fill the zone digit with the **EBCDIC** numeric subset code (**F**) when the __remainder__ field data type is alphanumeric (**UA**). When the __remainder__ field data type is signed numeric (**SN**), then the absolute value of the remainder is stored after the __remainder__ sign digit, leaving the __remainder__ sign digit with the original contents of the __dividend__ sign digit. Only the numeric digits of an alphanumeric field enter into the operation. Unsigned (**UN** or **UA**) operands are assumed to be positive. The sign of a __quotient__ is positive if the sign of the __divisor__ and the __dividend__ are the same or the __quotient__ is zero, otherwise the sign is negative. If the __dividend__ data type is **SN**, the sign of the __dividend__ will be left unchanged in memory and will thus become the sign of the __remainder__. Therefore this final __remainder__ sign could be other than *C* or *D* and a __remainder__ of zero magnitude could have a negative sign. If the operand data contains undigits other than in the sign digit, cause an //Invalid Arithmetic Data// fault. See [[compatibility_notes:a.16|Compatibility Notes A.16]]. ==== Comparison Flags ==== In all cases except overflow, set the [[processor_state:comparison_flags|Comparison Flags]] to indicate whether the sum is greater than (**HIGH**), equal to (**EQUAL**) or less than (**LOW**) zero.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-10 11:33 -0800 |
| Message-ID | <87o7p0pfjy.fsf@nosuchdomain.example.com> |
| In reply to | #89626 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> It would be a terrible idea for an efficient language to try to define
> what happens here, forcing compilers to generate pointless extra
> run-time checks just because some people have bugs in their code.
[...]
> It makes no sense for a language to try to define behaviour on
> division by zero - it is far better for the language to say "don't do
> that". Why someone would then want the language to say what will
> happen when you do something contrary to the rules of the language, is
> beyond my understanding.
[...]
Let me offer Ada as a counterexample (and I'm not suggesting that
C++ should follow Ada's example).
Signed numeric overflow and division by zero, along with a
number of other conditions like out of bounds array access and
dereferencing a null pointer, are defined in Ada to raise the
predefined Constraint_Error exception. If I write code that divides
by zero and then handles the exception, the behavior is well defined.
If I don't handle the exception, the program (or task, similar to
a thread) is aborted. The result of a division is either a well
defined numeric result or a well defined exception.
Since exceptions and the conditions that raise them are defined in
the language, optimizing compilers can omit a lot of checks if they
can prove that they'll never be triggered.
There are also language mechanisms to suppress checks. If a
check would have been triggered but is suppressed, the behavior
is undefined.
There is certainly a non-zero cost to this -- a cost that you can
avoid by suppressing checks -- but the cost is not all that great,
certainly less than the cost of using an interpreted language rather
than a compiled language.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-10 11:14 -0800 |
| Message-ID | <87sfecpgfm.fsf@nosuchdomain.example.com> |
| In reply to | #89616 |
Öö Tiib <ootiib@hot.ee> writes:
[...]
[...]
> C and C++ do not want to be portable assemblers of whatever chips,
> these want to be programming languages. From that viewpoint there
> are no reason why something that hardware does not handle (despite
> its cost to performance if handled is hard to notice) should be left
> undefined behavior.
[...]
You say there's "no reason", and then you explain in the same sentence
what the reason is: performance.
I don't see how the distinction between "portable assemblers" (which
pretty much do not exist) and programming languages is relevant.
--
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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-03-11 04:10 -0800 |
| Message-ID | <c3c9b792-b474-46a7-beb6-dda3fd308032n@googlegroups.com> |
| In reply to | #89648 |
On Friday, 10 March 2023 at 21:14:41 UTC+2, Keith Thompson wrote: > Öö Tiib <oot...@hot.ee> writes: > [...] > [...] > > C and C++ do not want to be portable assemblers of whatever chips, > > these want to be programming languages. From that viewpoint there > > are no reason why something that hardware does not handle (despite > > its cost to performance if handled is hard to notice) should be left > > undefined behavior. > [...] > > You say there's "no reason", and then you explain in the same sentence > what the reason is: performance. > Performance of elementary operations depends on hardware and it can choose to do something in parallel or as sequential micro-operations. There possibly is still hardware in usage where adding two integer registers takes multiple cycles but there is also hardware where 4 unrelated with each other adds in a row take one cycle. > I don't see how the distinction between "portable assemblers" (which > pretty much do not exist) and programming languages is relevant. > It is relevant in sense that its rules should be about usefulness for programming software. The throughput and latency of operations into what it is translated can change.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-12 12:06 +0100 |
| Message-ID | <tukbnh$31hii$2@dont-email.me> |
| In reply to | #89660 |
On 11/03/2023 13:10, Öö Tiib wrote: > On Friday, 10 March 2023 at 21:14:41 UTC+2, Keith Thompson wrote: >> Öö Tiib <oot...@hot.ee> writes: >> [...] >> [...] >>> C and C++ do not want to be portable assemblers of whatever chips, >>> these want to be programming languages. From that viewpoint there >>> are no reason why something that hardware does not handle (despite >>> its cost to performance if handled is hard to notice) should be left >>> undefined behavior. >> [...] >> >> You say there's "no reason", and then you explain in the same sentence >> what the reason is: performance. >> > Performance of elementary operations depends on hardware and it > can choose to do something in parallel or as sequential > micro-operations. There possibly is still hardware in usage where adding > two integer registers takes multiple cycles but there is also hardware > where 4 unrelated with each other adds in a row take one cycle. I don't see how that observation fits the points above it. However, it is worth noting that checked arithmetic - whether you are bounds-checking before the arithmetic, or using overflow or carry flags after the operation - absolutely cripples a modern processor's ability to do things in parallel. It enforces a serialisation that can only partially be offset by speculative execution. This cost is in addition to the sometimes severe limitations it enforces on compiler optimisations, expression re-arrangement, and code re-arrangement. > >> I don't see how the distinction between "portable assemblers" (which >> pretty much do not exist) and programming languages is relevant. >> > It is relevant in sense that its rules should be about usefulness for > programming software. The throughput and latency of operations into > what it is translated can change. The usefulness of C and C++ for programming is dependent on efficient code generation. If that is not relevant, switch to Python and get extending integers and exceptions on errors. (Plenty of programmers, and plenty of programs, would be better off with a language like Python, or at least a half-way choice like C#. "Trust the programmer" languages are not the right choice for all purposes.)
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-03-12 09:29 -0700 |
| Message-ID | <654e09c8-b5ab-49b0-b41c-51adf8a19fb2n@googlegroups.com> |
| In reply to | #89669 |
On Sunday, 12 March 2023 at 13:06:40 UTC+2, David Brown wrote: > On 11/03/2023 13:10, Öö Tiib wrote: > > On Friday, 10 March 2023 at 21:14:41 UTC+2, Keith Thompson wrote: > >> Öö Tiib <oot...@hot.ee> writes: > >> [...] > >> [...] > >>> C and C++ do not want to be portable assemblers of whatever chips, > >>> these want to be programming languages. From that viewpoint there > >>> are no reason why something that hardware does not handle (despite > >>> its cost to performance if handled is hard to notice) should be left > >>> undefined behavior. > >> [...] > >> > >> You say there's "no reason", and then you explain in the same sentence > >> what the reason is: performance. > >> > > Performance of elementary operations depends on hardware and it > > can choose to do something in parallel or as sequential > > micro-operations. There possibly is still hardware in usage where adding > > two integer registers takes multiple cycles but there is also hardware > > where 4 unrelated with each other adds in a row take one cycle. > > I don't see how that observation fits the points above it. However, it > is worth noting that checked arithmetic - whether you are > bounds-checking before the arithmetic, or using overflow or carry flags > after the operation - absolutely cripples a modern processor's ability > to do things in parallel. It enforces a serialisation that can only > partially be offset by speculative execution. This cost is in addition > to the sometimes severe limitations it enforces on compiler > optimisations, expression re-arrangement, and code re-arrangement. > Point is simply that things can and are made differently on hardware level. You talk about software level checks before or after operation. The expressions that are rearranged or ran in parallel are anyway proven to be unrelated by compiler or hardware that does those. > > > >> I don't see how the distinction between "portable assemblers" (which > >> pretty much do not exist) and programming languages is relevant. > >> > > It is relevant in sense that its rules should be about usefulness for > > programming software. The throughput and latency of operations into > > what it is translated can change. > > The usefulness of C and C++ for programming is dependent on efficient > code generation. If that is not relevant, switch to Python and get > extending integers and exceptions on errors. (Plenty of programmers, > and plenty of programs, would be better off with a language like Python, > or at least a half-way choice like C#. "Trust the programmer" languages > are not the right choice for all purposes.) > There are needs where such choice is not available and so I have very low experience with C# and Python. Also to throw decades of experience away and to say that nah I now just make JavaScript for web page would be irresponsible.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-03-09 15:26 +0100 |
| Message-ID | <tucq7r$1ftbg$1@dont-email.me> |
| In reply to | #89514 |
Am 07.03.2023 um 22:38 schrieb Lynn McGuire: > "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 > Read this: https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2023-03-09 16:59 -0600 |
| Message-ID | <tudobq$1l3ft$1@dont-email.me> |
| In reply to | #89575 |
On 3/9/2023 8:26 AM, Bonita Montero wrote: > Am 07.03.2023 um 22:38 schrieb Lynn McGuire: >> "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 >> > > Read this: > https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM No freaking way. Looks like a ransomware file to me. Lynn
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-03-10 05:59 +0100 |
| Message-ID | <tuedcj$1r4lp$1@dont-email.me> |
| In reply to | #89594 |
Am 09.03.2023 um 23:59 schrieb Lynn McGuire: > On 3/9/2023 8:26 AM, Bonita Montero wrote: >> Read this: >> https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM > No freaking way. Looks like a ransomware file to me. Ransomware in a PDF or EPUB ?
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2023-03-10 09:17 +0100 |
| Message-ID | <tuep2r$1srfq$1@dont-email.me> |
| In reply to | #89598 |
On 2023-03-10 5:59 AM, Bonita Montero wrote: > Am 09.03.2023 um 23:59 schrieb Lynn McGuire: > >> On 3/9/2023 8:26 AM, Bonita Montero wrote: > >>> Read this: >>> https://mega.nz/file/ehcR1S5B#5YcRMdcJ0WArshD0szI2bckaqVmk2jC59XmOZh_GXgM > >> No freaking way. Looks like a ransomware file to me. > > Ransomware in a PDF or EPUB ? When the first .jpg virus was discovered in 2002 I was happy, well a little, because it was an obvious possibility to me but my students laughed at me when I mentioned it, middle 1990's. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-03-10 13:38 +0100 |
| Message-ID | <tuf8a8$1vdg4$1@dont-email.me> |
| In reply to | #89601 |
Am 10.03.2023 um 09:17 schrieb Alf P. Steinbach: > When the first .jpg virus was discovered in 2002 I was happy, well > a little, because it was an obvious possibility to me but my students > laughed at me when I mentioned it, middle 1990's. There might be an inconsistent content inside the file which might cause intentional "misinterpretation" by the parser. But that's rather unlikely.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-03-10 05:10 -0800 |
| Message-ID | <5d98c0ee-b119-4770-b702-9ec73647b5ben@googlegroups.com> |
| In reply to | #89617 |
On Friday, March 10, 2023 at 2:37:43 PM UTC+2, Bonita Montero wrote: > Am 10.03.2023 um 09:17 schrieb Alf P. Steinbach: > > > When the first .jpg virus was discovered in 2002 I was happy, well > > a little, because it was an obvious possibility to me but my students > > laughed at me when I mentioned it, middle 1990's. > There might be an inconsistent content inside the file which might > cause intentional "misinterpretation" by the parser. But that's > rather unlikely. Today .jpg viruses are indeed not likely. But PDF is inherently more vulnerable than jpeg. Even on the most basic level of functionality PDF is an encapsulated PostScript, which is Turing-complete programming languge. Above that PDF often contain other embedded formats that are expected to be displayed by the viewer. And above all that many PDF viewers support JS scripts in the documents.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web