Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I have always understood it this way: the purpose of the <code>iostream</code> class is to read and/or write a stream of characters, which, if you think about it, are abstract entities that are only represented by the computer using a character encoding. The C++ standard makes great pains to avoid pinning down the character encoding, saying only that "Objects declared as characters (<code>char</code>) shall be large enough to store any member of the implementation's basic character set," because it doesn't need to force the "implementation basic character set" to define the C++ language; the standard can leave the decision of <em>which</em> character encoding is used to the implementation (compiler together with an STL implementation), and just note that <code>char</code> objects represent single characters in some encoding.</p> <p>An implementation writer could choose a single-octet encoding such as <a href="http://en.wikipedia.org/wiki/ISO/IEC_8859-1" rel="noreferrer">ISO-8859-1</a> or even a double-octet encoding such as <a href="http://en.wikipedia.org/wiki/UCS-2" rel="noreferrer">UCS-2</a>. It doesn't matter. As long as a <code>char</code> object is "large enough to store any member of the implementation's basic character set" (note that this explicitly forbids <a href="http://en.wikipedia.org/wiki/Variable-width_encoding" rel="noreferrer">variable-length encodings</a>), then the implementation may even choose an encoding that represents basic Latin in a way that is incompatible with any common encoding!</p> <p>It is confusing that the <code>char</code>, <code>signed char</code>, and <code>unsigned char</code> types share "char" in their names, but it is important to keep in mind that <code>char</code> does not belong to the same family of fundamental types as <code>signed char</code> and <code>unsigned char</code>. <code>signed char</code> is in the family of signed integer types:</p> <blockquote> <p>There are four <em>signed integer types</em>: "signed char", "short int", "int", and "long int."</p> </blockquote> <p>and <code>unsigned char</code> is in the family of unsigned integer types:</p> <blockquote> <p>For each of the signed integer types, there exists a corresponding (but different) <em>unsigned integer type</em>: "unsigned char", "unsigned short int", "unsigned int", and "unsigned long int," ...</p> </blockquote> <p>The one similarity between the <code>char</code>, <code>signed char</code>, and <code>unsigned char</code> types is that "[they] occupy the same amount of storage and have the same alignment requirements". Thus, you can <code>reinterpret_cast</code> from <code>char *</code> to <code>unsigned char *</code> in order to determine the numeric value of a character in the execution character set.</p> <p>To answer your question, the reason why the STL uses <code>char</code> as the default type is because the standard streams are meant for reading and/or writing streams of characters, represented by <code>char</code> objects, not integers (<code>signed char</code> and <code>unsigned char</code>). The use of <code>char</code> versus the numeric value is a way of separating concerns.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload