Pourquoi les flux C ++ utilisent-ils char au lieu de char non signé?

Question

Je me suis toujours demandé pourquoi la bibliothèque standard C ++ avait instancié le flux basic_ [io] et toutes ses variantes en utilisant le type char au lieu du type chars non signés . char signifie (selon qu'il soit signé ou non), vous pouvez avoir un débordement ou un débordement pour des opérations comme get (), ce qui conduira à une valeur définie par l'implémentation des variables impliquées. Un autre exemple est lorsque vous souhaitez générer un octet, non formaté, dans un ostream à l'aide de sa fonction put .

Des idées?

Remarque : je ne suis toujours pas vraiment convaincu. Donc, si vous connaissez la réponse définitive, vous pouvez toujours la poster.

Answer 1

J'ai peut-être mal compris la question, mais la conversion d'un caractère non signé en caractère n'est pas non spécifiée, elle dépend de la mise en œuvre (4.7-3 dans la norme C ++).

Le type d'un caractère de 1 octet en C ++ est "car", pas "car non signé". Cela donne aux implémentations un peu plus de liberté pour tirer le meilleur parti de la plate-forme (par exemple, l’organisme de normalisation a peut-être cru qu’il existait des CPU où l'arithmétique en octets signés était plus rapide que l'arithmétique en octets non signés, bien que ce soit de la spéculation de ma part). Aussi pour la compatibilité avec C. Le résultat de la suppression de ce type d’incertitude existentielle de C ++ est C #; -)

Etant donné que le & char; char " type existe, je pense qu'il est logique que les flux habituels l'utilisent même si sa signature n'est pas définie. Alors peut-être répondez-vous à votre question, "Pourquoi le C ++ n’a-t-il pas simplement défini le caractère comme étant non signé?"

Answer 2

Je l’ai toujours compris ainsi: le but de la classe iostream est de lire et / ou d’écrire un flux de caractères qui, si vous y réfléchissez, sont des entités abstraites qui ne sont que représenté par l'ordinateur à l'aide d'un codage de caractères. La norme C ++ s'efforce d'éviter d'épingler le codage de caractères en précisant que les "Objets déclarés en tant que caractères ( char ) doivent être suffisamment grands pour stocker tout membre du jeu de caractères de base de l'implémentation". car il n’est pas nécessaire de forcer le & jeu; jeu de caractères de base d’implémentation " définir le langage C ++; la norme peut laisser la décision de quel codage de caractères est utilisé pour l'implémentation (compilateur avec une implémentation STL), et il suffit de noter que les objets char représentent des caractères uniques dans certains encodages .

Un rédacteur d'implémentation pourrait choisir un codage à un octet tel que ISO-8859-1 ou même un codage à double octet tel que UCS-2 . Ça n'a pas d'importance. Tant qu'un objet char est "suffisamment grand pour stocker n'importe quel membre du jeu de caractères de base de la mise en oeuvre" (notez que cela interdit explicitement les encodages de longueur variable ), alors l'implémentation peut même choisir un codage qui représente le latin de base d’une manière incompatible avec tout codage courant!

Il est déroutant que les types char , chars signés et chars non signés partagent " char " dans leurs noms, mais il est important de garder à l'esprit que char n'appartient pas à la même famille de types fondamentaux que char signé et char non signé . caractère signé appartient à la famille des types entiers signés:

  

Il existe quatre types entiers signés : "caractère signé", "short int", "int" et "long int."

et le caractère non signé appartient à la famille des types entiers non signés:

  

Pour chacun des types d'entiers signés, il existe un type d'entier non signé correspondant (mais différent): "unsigned char", "unsigned short int", "unsigned int", et "unsigned long int," ...

La seule similitude entre les types car , car et char non signés est que "ils occupent le même nombre de stockage et ont les mêmes exigences d’alignement ". Ainsi, vous pouvez réinterpréter_cast de char * à char non signé * afin de déterminer la valeur numérique d'un caractère du jeu de caractères d'exécution. / p>

Pour répondre à votre question, la raison pour laquelle la STL utilise char comme type par défaut est que les flux standard sont conçus pour la lecture et / ou l'écriture de flux de caractères, représentés par char objets, pas entiers ( chars signés et chars non signés ). L'utilisation de char par rapport à la valeur numérique est un moyen de séparer les préoccupations.

Answer 3

char est pour les caractères, char non signé pour les octets bruts de données, et les caractères signés pour, ainsi, les données signées.

Standard ne spécifie pas si le caractère signé ou non signé sera utilisé pour l'implémentation de caractère - il est spécifique au compilateur. Il spécifie seulement que le caractère "& char" " sera " suffisant " pour conserver des caractères sur votre système - comme les personnages à l’époque, c’est-à-dire sans UNICODE.

Utilisation de & char; char " pour les personnages est la voie standard à suivre. Utiliser un caractère non signé est un hack, bien que cela corresponde à la mise en oeuvre du caractère par le compilateur sur la plupart des plateformes.

Answer 4

Je pense que ce commentaire l'explique bien. Pour citer:

  

char char et unsigned char sont des types arithmétiques, entiers, tout comme int et unsigned int. D'autre part, char est expressément destiné à être le "I / O" Type représentant une unité de données fondamentale opaque et spécifique au système sur votre plate-forme. Je les utiliserais dans cet esprit.