1

Why was char in C++14 ever defined as specifically one less than the amount of values that a char could hold before, and what was their reasoning for changing such things for the C++14 Standard? It appears that from http://en.cppreference.com/w/cpp/language/types that C++14 has changed the lower limit from -127 to -128.

Does this break compatibility with ones' complements systems? What was their rationale for even changing the bounds at all?

thecoshman
  • 8,394
  • 8
  • 55
  • 77
CinchBlue
  • 6,046
  • 1
  • 27
  • 58
  • Whether `char` is signed or unsigned, and its range (minimum 256), is implementation defined. – Neil Kirk Mar 09 '15 at 04:31
  • -128 is the minimum twos complement for an 8 bit value...what are you asking? – old_timer Mar 09 '15 at 04:31
  • C++14 §3.9.1/7 clearly says "[Example: this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types. —end example ]" – Adam Rosenfield Mar 09 '15 at 04:31
  • The change in C++14 was to require that bytes (and, consequently, chars) now must support at least 256 distinct values, which is what cppreference interpreted as widening the range. – Cubbi Apr 27 '15 at 04:24
  • Ah, I see. But this still doesn't answer the question of whether it breaks compatibility with ones complements – CinchBlue Apr 27 '15 at 06:39

1 Answers1

2

No, I misunderstood the change; the "change of bounds" did not. In fact, the only change wass that C++14 required bytes to now hold 256 distinct values, which was already within the capabilities of the typical byte data structure before hand.

C++ does not restrict its implementations by requiring a specific binary representation for its integral types, which means that architectures are free to remain conformant to the C++ Standard even if they decide to use a non-standard binary representation for integral types.

From Section 3.9.1 of the C++14 Standard Working Draft, Fundamental Types:

7 Types bool , char , char16_t , char32_t , wchar_t , and the signed and unsigned integer types are collectively called integral types. A synonym for integral type is integer type. The representations of integral types shall define values by use of a pure binary numeration system.

[Example: this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types. —end example ]

If we do calculate the amount of values a single char value can hold, it can be seen that C++14 increases the negative space of a char by one for a total of 256 unique values (including 0). I would guess that prior versions left the bottom limit for a char at -128 for compatibility with ones' complement systems.

Edit: The misunderstanding is that ones' complements still can hold 256 values; it's just that two "represent" 0, as +0 and -0. If we take one to mean something else, we can then pretend that we still have 256 assignable values and thus, enough space to fit the char requirement for C++14.

Related: Why not enforce 2's complement in C++?

C++14 Standard Working Draft: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf

Community
  • 1
  • 1
CinchBlue
  • 6,046
  • 1
  • 27
  • 58
  • I am not sure +0 and -0 can be treated separately. 3.9.1/1 says that integral conversion must be able to convert those 256 values into 0..255 of unsigned char, but 4.7/2 appears to describe this in terms of integer values – Cubbi Apr 27 '15 at 14:23