Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2232
| From | Hans Aberg <haberg-news@telia.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Optimization techniques, C++ numeric representations |
| Date | 2019-04-30 15:01 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <19-04-048@comp.compilers> (permalink) |
| References | <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-020@comp.compilers> <19-04-033@comp.compilers> <19-04-043@comp.compilers> |
On 2019-04-29 17:24, David Brown wrote: > On 27/04/2019 23:01, Hans Aberg wrote: >> On 2019-04-25 17:46, Martin Ward wrote: >>> If signed overflow was given a defined >>> behaviour (such as the two's complement result), then compilers for >>> CPUs which do not implement two's complement operations would have to >>> generate less efficient code (but does anyone still make such a CPU?). >> >> All C++ compilers use two's complement, and as of C++20, that is >> required, cf. [1], "Range of values". It is required for int32_t etc in >> C++11 [2] and C99 [3]. >> >> 1. https://en.cppreference.com/w/cpp/language/types >> 2. https://en.cppreference.com/w/cpp/types/integer >> 3. https://en.cppreference.com/w/c/types/integer >> [I realize that if you look very hard, you can still find a few legacy >> machines that are not pure two's complement and do not have 8-bit byte >> addressing. But these days, so what. -John] > > Note, however, that this applies only to the representation of the > types. C++20 will /not/ require two's complement wrapping on signed > integer overflow - this will remain undefined behaviour. (And, as > always, compilers are free to define it if they want.) For that, one will have to use the unsigned types. It is required in Java, though, which does not have the unsigned type. So the question is why UB is kept in C/C++. There is a list of languages here: https://en.wikipedia.org/wiki/Integer_overflow
Back to comp.compilers | Previous | Next — Previous in thread | Find similar
Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-25 16:46 +0100
Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-25 23:01 +0000
Re: Optimization techniques alexfrunews@gmail.com - 2019-04-26 01:33 -0700
Re: language design and Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-27 11:56 +0100
Re: Optimization techniques 0xe2.0x9a.0x9b@gmail.com - 2019-04-27 04:56 -0700
Re: C language andOptimization techniques alexfrunews@gmail.com - 2019-04-27 19:47 -0700
Re: reliability features and Optimization techniques Bart <bc@freeuk.com> - 2019-04-28 11:58 +0100
Re: reliability features and Optimization techniques Jan Ziak <0xe2.0x9a.0x9b@gmail.com> - 2019-04-29 04:33 -0700
Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:11 -0700
Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-07 16:43 +0200
Re: Optimization techniques Hans Aberg <haberg-news@telia.com> - 2019-04-27 23:01 +0200
Re: Optimization techniques, C++ numeric representations David Brown <david.brown@hesbynett.no> - 2019-04-29 17:24 +0200
Re: Optimization techniques, C++ numeric representations Hans Aberg <haberg-news@telia.com> - 2019-04-30 15:01 +0200
csiph-web