char, unsigned char y signed char

[vangodp]

Hola compañeros, sigo aquí estudiando el C/C++. Tengo una duda que como mínimo es del más curiosa.

En la tabla asc2 la letra 'Ç' tiene como posición el numero 128 correcto? Por que cuando hago char letra = 'Ç'; muestra resultados raros, ya me mostró -57, luego me mostró 199 y yo que sé jajaja.

Me siento como los novatillos del primer día vamos jajaj
Este me dá -57

Código C:

#include<stdio.h>
 
int main(){
    
    char l = 'Ç';
    printf("%d", l);
        
    return 0;
}
 

Luego este me da 199

Código C:

unsigned char l = 'Ç';
    printf("%d", l);
 

Será por el especificador %d no es el correcto? La cosa es que ya intenté de todo, unsigned, %u, casts, tipos de char signed y unsigned y ya no sé que más intento. A ver si a vosotros os ocurre lo mismo


Un saludo!

[enrieto]

Jé. A mí me muestra -121 y 135 :)

En la tabla asc2 la letra 'Ç' tiene como posición el numero 128 correcto?

No, no lo es.

Supongo que "tabla asc2" debe ser una tabla de caracteres ascii extendida, esa con 255 caracteres, ¿no?
Bueno, ese tipo de tablas es propia de un cierto "juego de caracteres", dentro de un cierto "codepage". (Si te interesa la arqueología informática, en http://www.custombit.com.ar/acentos/ se puede bajar "acentos y otras yerbas", que es un mapa de caracteres de la época de Tutanquieto que está basado en ascii extendido).

La razón por la que estás viendo dos resultados distintos es que en tu compilador el tipo char es un "signed char" por defecto. Si te fijás debe haber por ahí algún seteo o flag para que el compilador tome un char como "unsigned char".

Por otro lado, lo que vaya a mostrar tu programa también depende del editor de texto que estés usando para escribir el código... que no es lo mismo poner 'Ç' cuando el editor usa un encoding Ansi, que cuando está usando UTF-8 o UTF-16, que es lo más frecuente, porque lo que se ve por pantalla puede ser el mismo dibujito, pero su representación en bits es otra.

Si alguien pidiera mi consejo, yo le diría que abandone los asciis y ansis, y que empiece leyendo "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)"
http://www.joelonsoftware.com/articles/Unicode.html

[eferion]

Yo estos problemas los evito usando Qt (o en su defecto cualquier librería que proporcione soporte para multi-idioma.

Esta es una de las grandes flaquezas de C++. Usar un juego de caracteres diferente al ASCII (que es ya de por si limitado con ganas) puede llegar a ser un quebradero de cabeza importante.

Y si ya la aplicación tiene que correr en diferentes plataformas pasas a meterte en un jardín de cuidado jejeje

Un saludo.

[vangodp]

pffff no entiendo nada, lo único que saco en claro es que no me debo fiar de lo que hay del valor de 127 a cima. No hay alguna lectura sobre el tema en español? Mi inglish is very bad =D
Gracias chicos por responder.

[eferion]

Dicho con pocas palabras: los caracteres en C no son más que números que se comparan con una tabla para mostrar texto al usuario. La misma secuencia de números mostrará mensajes distintos al usar tablas diferentes:

1232 con (1=R,2=A,3=N) da RANA
1232 con (1=T,2=O,3=D) da TODO
1232 con (12=F,3=I,2=N) da FIN (hay codificaciones que emplean un número variable de bytes para cada carácter)

La codificación por defecto en C es ASCII y la misma son 127 caracteres (255 la extendida). Se pueden usar otras codificaciones pero entonces las funciones de string.h dejan de ser funcionales pues asumen que la codificación empleada es ASCII.

Un saludo.

[vangodp]

Gracias compañero, eres un genio. Voy a ponerme las pilas con el tema, seguramente volvere más veces. >_<

[eferion]

No es necesario empollar demasiado el tema. Existen clases completamente funcionales para enmascarar estos problemas en C y C++. Yo personalmente uso Qt, sobretodo por temas laborales, y su clase QString va de lujo con cualquier codificación.

[vangodp]

Pero Qt no es libre verdad? Además se suma un aprendizaje extra... y bien 'complicailla' es >_< Pero eso sí... tengo entendido que es la caña, no la uso mismo porque el tema de las licencias me tiene un poco así despistado. XD

[eferion]

Para proyectos caseros u opensource no vas a tener problemas con la licencia.

En el caso de proyectos comerciales podrás programar con Qt sin problemas si te quedas en la versión 4.

[enrieto]

Una opción del C++ estándar es wchar_t y std::wstring.

A ver si me sale poner una imagen con textos generados por un programa C++ (promo para la venta de una dll) que sólo usa wstring en su motor:

[eferion]

El problema de wchar_t (y por extensión wstring) es la portabilidad. Las distros de linux suelen hacer uso de codificación unicode para wchar_t mientras que windows opta por UTF-16.

Como las tablas no son equivalentes el fuente no puede ser portado alegremente entre plataformas.

[enrieto]

Iniciado por eferion

El problema de wchar_t (y por extensión wstring) es la portabilidad. Las distros de linux suelen hacer uso de codificación unicode para wchar_t mientras que windows opta por UTF-16.

Como las tablas no son equivalentes el fuente no puede ser portado alegremente entre plataformas.

No, estás equivocado, no existe ningún "problema de portabilidad", tanto wchar_t como wstring son estándares C++.

No es mala idea empezar con la lectura de ese artículo de Joel Spolsky que mencioné en un post anterior, sobre "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)"

[eferion]

Iniciado por enrieto

No, estás equivocado, no existe ningún "problema de portabilidad", tanto wchar_t como wstring son estándares C++.

No es mala idea empezar con la lectura de ese artículo de Joel Spolsky que mencioné en un post anterior, sobre "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)"

Tengo la mala costumbre de recurrir a stackoverflow cuando dudo sobre algún aspecto del lenguaje... por eso de que hay gente en ese foro que ya redactaba partes del estándar antes de nacer. En este hilo por ejemplo se explica por qué no es una alternativa de cara a hacer código portable entre Windows y Linux. Y en este otro recomiendan, como norma general, no usar wchar_t y wstring salvo que no tengas alternativa.

Y no son los únicos sitios en los que se comenta que los tipos que vienen en el estándar de C++ para la gestión de cadenas son útiles para introducirse en el lenguaje y poco más.

Claro que se pueden hacer cosas con string y wstring pero su especificación tiene ciertas lagunas y carencias.

Por otro lado no tengo nada en contra de quien se empeña en conseguir que esa clase sea útil de verdad.

Yo personalmente ni las uso ni las hecho de menos y mira que trabajo con C++ 5 días a la semana 8 horas al día desde hace 5 años.

Un saludo.

[enrieto]

engo la mala costumbre de recurrir a stackoverflow cuando dudo sobre algún aspecto del lenguaje...

Bueno, yo también consulto habitualmente ese sitio, por supuesto, pero también entiendo que el valor de autoridad que puede tener no es universal. A propósito, quizá también te impresione saber que el autor del artículo que recomendaba es el creador de Stackoverflow.

Estaba viendo la segunda discusión que mencionas, [URL="http://stackoverflow.com/questions/402283/"]std::wstring VS std::string[/URL], y no veo que la conclusión sea que se deba evitar wchar_t o wstring, para nada. Por otro lado, la respuesta más votada es por demás inconsistente, y yo no sacaría ninguna conclusión a partir de ella, ni la que vos suponías ni ninguna otra. Basta prestar atención a uno de los comentarios

While this examples produces different results on Linux and Windows the C++ program contains implementation-defined behavior as to whether olè is encoded as UTF-8 or not. Further more, the reason you cannot natively stream wchar_t * to std::cout is because the types are incompatible resulting in an ill-formed program and it has nothing to do with the use of encodings. It's worth pointing out that whether you use std::string or std::wstring depends on your own encoding preference rather than the platform, especially if you want your code to be portable. – John Leidegren Aug 9 '12 at 9:37

En mi humilde experiencia, wchar_t y wstring han hecho lo que se esperaba de ellas. sin importar si era en ruso o castellano, si en Windows o en Linux. Debe ser que como no soy académico nunca encontré incompatibilidades.