What assumption is safe for a C++ implementation's character set?

Question

In The C++ Programming Language 6.2.3, it says:

It is safe to assume that the implementation character set includes the decimal digits, the 26 alphabetic characters of English, and some of the basic punctuation characters. It is not safe to assume that:

• There are no more than 127 characters in an 8-bit character set (e.g., some sets provide 255 characters).

• There are no more alphabetic characters than English provides (most European languages provide more, e.g., æ, þ, and ß).

• The alphabetic characters are contiguous (EBCDIC leaves a gap between 'i' and 'j').

• Every character used to write C++ is available (e.g., some national character sets do not provide {, }, [, ], |, and \).

• A char fits in 1 byte. There are embedded processors without byte accessing hardware for which a char is 4 bytes. Also, one could reasonably use a 16-bit Unicode encoding for the basic chars.

I'm not sure I understand the last two statements.

In section 2.3 of the standard, it says:

The basic source character set consists of 96 characters: the space character, the control characters representing horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:

a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > % : ; . ? * + - / ^ & | ! = , \ " '
...

The basic execution character set and the basic execution wide-character set shall each contain all the members of the basic source character set, plus control characters representing alert, backspace, and carriage return, plus a null character (respectively, null wide character), whose representation has all zero bits.

We can see that it is stated by the standard that characters like { } [ ] | \ are part of the basic execution character set. Then why TC++PL says it's not safe to assume that those characters are available in the implementation's character set?

And for the size of a char, in section 5.3.3 of the standard:

The sizeof operator yields the number of bytes in the object representation of its operand. ... ... sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1.

We can see that the standard states that a char is of 1 byte. What is the point TC++PL trying to make here?

Answer 1

• The word "byte" seems to be used sloppily in the first quote. As far as C++ is concerned, a byte is always a char, but the number of bits it holds is platform-dependent (and available in CHAR_BITS). Sometimes you want to say "a byte is eight bits", in which case you get a different meaning, and that may have been the intended meaning in the phrase "a char has four bytes".

• The execution character set may very well be larger than or incompatible with the input character set provided by the environment. Trigraphs and alternate tokens exist to allow the representation of execution-set characters with fewer input characters on such restricted platforms (e.g. not is identical for all purposes to !, and the latter is not available in all character sets or keyboard layouts).

Answer 2

It used to be the case that some national variants of ASCII, such as the Scandinavian languages, used accented alphabetic characters for the code points where US ASCII has punctuation such as [, ], {, }. These are the reason that C89 included trigraphs — they allow code to be written in the 'invariant subset' of ISO 646. See the chart of the characters used in the national variants on the Wikipedia page.

For example, someone in Scandinavia might have to read:

#include <stdio.h>

int main(int argc, char **argv)
Å
    for (int i = 1; i < argc; i++)
        printf("%s\n", argvÆiØ);
    return 0;
ø

instead of:

#include <stdio.h>

int main(int argc, char **argv)
{
    for (int i = 1; i < argc; i++)
        printf("%s\n", argv[i]);
    return 0;
}

Using trigraphs, you might write:

??=include <stdio.h>

int main(int argc, char **argv)
??<
    for (int i = 1; i < argc; i++)
        printf("%s??/n", argv??(i??));
    return 0;
??>

which is equally ghastly in any language.

I'm not sure how much of an issue this still is, but that's why the comments are there.