Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #2232

Re: Optimization techniques, C++ numeric representations

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>

Show all headers | View raw


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 | NextPrevious in thread | Find similar


Thread

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