¿Por qué las transmisiones de C ++ usan char en lugar de char sin firmar?

Question

Siempre me he preguntado por qué la biblioteca estándar de C ++ ha instanciado el flujo basic_ [io] y todas sus variantes utilizando el tipo char en lugar del tipo unsigned char . char significa (dependiendo de si está firmado o no) puede tener desbordamiento y desbordamiento para operaciones como get (), lo que conducirá a un valor definido por la implementación de las variables involucradas. Otro ejemplo es cuando desea emitir un byte, sin formato, a una corriente de entrada utilizando su función put .

¿Alguna idea?

---

Nota : todavía no estoy realmente convencido. Entonces, si conoce la respuesta definitiva, aún puede publicarla.

Answer 1

Posiblemente no he entendido bien la pregunta, pero la conversión de char sin firmar a char no está especificada, depende de la implementación (4.7-3 en el estándar C ++).

El tipo de un carácter de 1 byte en C ++ es "char", no "unsigned char". Esto le da a las implementaciones un poco más de libertad para hacer lo mejor en la plataforma (por ejemplo, el organismo de estándares puede haber creído que existen CPU donde la aritmética de bytes firmados es más rápida que la aritmética de bytes no firmados, aunque eso es especulación de mi parte). También por compatibilidad con C. El resultado de eliminar este tipo de incertidumbre existencial de C ++ es C # ;-)

Dado que el " char " El tipo existe, creo que tiene sentido que las corrientes habituales lo usen aunque su firma no esté definida. Entonces, tal vez su pregunta sea respondida por la respuesta a, "¿por qué C ++ simplemente no definió char como sin signo?"

Answer 2

Siempre lo he entendido así: el propósito de la clase iostream es leer y / o escribir una secuencia de caracteres que, si lo piensas, son entidades abstractas que son solo representado por la computadora usando una codificación de caracteres. El estándar C ++ hace grandes esfuerzos para evitar precisar la codificación de caracteres, diciendo solo que " Los objetos declarados como caracteres ( char ) serán lo suficientemente grandes como para almacenar cualquier miembro del conjunto de caracteres básico de la implementación, " porque no necesita forzar el " conjunto de caracteres básicos de implementación " para definir el lenguaje C ++; el estándar puede dejar la decisión de qué codificación de caracteres se utiliza para la implementación (compilador junto con una implementación STL), y solo tenga en cuenta que los objetos char representan caracteres individuales en alguna codificación .

Un escritor de implementación podría elegir una codificación de un solo octeto como ISO-8859-1 o incluso una codificación de doble octeto como UCS-2 . No importa. Siempre que un objeto char sea lo suficientemente grande como para almacenar cualquier miembro del conjunto de caracteres básico de la implementación " (tenga en cuenta que esto prohíbe explícitamente codificaciones de longitud variable ), entonces la implementación puede incluso elegir un ¡codificación que representa latín básico de una manera que es incompatible con cualquier codificación común!

Es confuso que los tipos char , igned char y unsigned char compartan " char " en sus nombres, pero es importante tener en cuenta que char no pertenece a la misma familia de tipos fundamentales que igned char y unsigned char . igned char pertenece a la familia de tipos enteros firmados:

  

Hay cuatro tipos de entero con signo : "char con signo", "int corto", "int" y "largo int."

y unsigned char pertenece a la familia de tipos enteros sin signo:

  

Para cada uno de los tipos de enteros con signo, existe un tipo de entero sin signo correspondiente : " unsigned char " ;, " unsigned short int " ;, " unsigned int " ;, y " unsigned long int " ...

La similitud entre los tipos char , igned char y unsigned char es que " [ellos] ocupan la misma cantidad de almacenamiento y tienen los mismos requisitos de alineación ''. Por lo tanto, puede reinterpret_cast de char * a unsigned char * para determinar el valor numérico de un carácter en el conjunto de caracteres de ejecución.

Para responder a su pregunta, la razón por la cual el STL usa char como el tipo predeterminado es porque las secuencias estándar están destinadas a leer y / o escribir secuencias de caracteres, representadas por char objetos, no enteros ( char firmado y char firmado ). El uso de char versus el valor numérico es una forma de separar las preocupaciones.

Answer 3

char es para caracteres, char sin firmar para bytes sin procesar de datos y caracteres firmados para, bueno, datos firmados.

El estándar no especifica si se utilizará char con signo o sin signo para la implementación de char; es específico del compilador. Solo especifica que el '' char '' será "suficiente" para mantener los caracteres en su sistema, como eran los caracteres en esos días, es decir, sin UNICODE.

Usando " char " para los personajes es el camino estándar a seguir. El uso de char sin firmar es un truco, aunque coincidirá con la implementación del compilador de char en la mayoría de las plataformas.

Answer 4

Creo que este comentario lo explica bien. Para citar:

  

igned char y unsigned char son tipos integrales aritméticos, como int y unsigned int. Por otro lado, char está expresamente destinado a ser la E / S tipo que representa alguna unidad de datos fundamental opaca y específica del sistema en su plataforma. Los usaría con este espíritu.