-1

If I declare signed char k = 'a' then will the value of k not be 97, which is the ASCII value of 'a', as the range of signed char is -128 to 127?

If not then what does it mean by range of signed char?

Niall
  • 30,036
  • 10
  • 99
  • 142
TESLA____
  • 1,019
  • 7
  • 9

2 Answers2

0

Why would a value suddenly change? The ASCII table is a list of constants, and 'a' always matches 97 in any language/environment that conforms to the ASCII-standards (so more or less all of them).

The range consists of the minimum and maximum value that can be contained in a variable of a given type.

A signed char has 8 bits of which 1 for the sign, meaning 7 bits of actual data and it can be positive or negative. Therefore it can contain integer values between -128 and 127.

An unsigned char has 8 bits, all for actual data, meaning it can contain integer values between 0 and 255.

(the above is naively assuming a modern system in which a char contains 8 bits, it could theoretically be more. Also, as explained in that link, the bottom limit of a signed char could also be -127 on your specific system - use limits.h to be sure)

Community
  • 1
  • 1
Niels Keurentjes
  • 41,402
  • 9
  • 98
  • 136
  • What do you mean by " (ie. all of them)." ? There are non-ASCII systems (although IDK if any non-ASCII system ever had an ISO C++ compliant compiler) – M.M Sep 16 '14 at 19:49
  • @MattMcNabb with enough users to be practical for the purposes of this answer? That's about as likely as running into the system where a `char` actually has 10 bits. – Niels Keurentjes Sep 16 '14 at 19:51
  • well if you're going to mention one corner case maybe mention them all..:) it's also theoretically possible that `signed char` will use one's complement or sign-magnitude in which case the minimum value would be `-127`. (But again I don't know if anyone ever did that for C++, although they certainly did for C) – M.M Sep 16 '14 at 19:52
  • Well I changed it to 'more or less all of them' now, should make the nitpickers happy :P – Niels Keurentjes Sep 16 '14 at 19:54
  • IBM has a C++ compiler for zOS (which was the reason for not removing trigraphs) – AProgrammer Sep 16 '14 at 19:54
0

I'm not sure if this is what you're asking, but the C++ standard promises that all of the characters in the basic execution character set will be non-negative. From C++11 2.3/3 :

For each basic execution character set, the values of the members shall be non-negative and distinct from one another

The basic execution character set is the 26 letters (upper and lower case) a-z and A-Z, the digits 0-9, most the set of punctuation marks that are in the ASCII character set (for example, '$' and '@' are not included) as well as space and a few core control characters.

However, other characters might have a negative representation when signed char is used. For example, in one possible code page the Euro character, '€', has a value of 128 if char is unsigned, but a value of -128 if char is signed.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • Was that quote in C++03? It excludes EBCDIC systems with signed char. – M.M Sep 16 '14 at 20:07
  • Yes, C++03 says the same thing. I haven't used EBCDIC systems, but a glance at Wikipedia's table makes it look like unsigned char or a `char` type with more than 8 bits would be needed to comply with that requirement. A point of interest - the C standard (up through C11) does *not* require that these values be non-negative. I'm a little surprised at the difference in this detail between C and C++, but not a whole lot. Is EBCDIC more than a historical curiosity anymore? – Michael Burr Sep 16 '14 at 21:24
  • @MichaelBurr This is wrong. ISO C99 says in 6.2.5p3: "If a member of the basic execution character set is stored in a `char` object, its value is guaranteed to be nonnegative." Thus it has the same requirement as C++03. This means that an EBCDIC implementation must have `char` behaving like `unsigned char`. See also: https://stackoverflow.com/questions/45123003/do-a-and-0-always-have-positive-values-even-if-char-is-signed – vinc17 Nov 10 '20 at 13:35