Discussion :

[Herode]

Bonjour � tous,

j'ai un petit souci, d� au fait que le compilateur refuse de transtyper du const char* (qui m'arrive en entr�e) vers du const unsigned char*, ce dernier type �tant requis par une librairie que je dois utiliser.

Remarquez que je ne lui en veux pas, sur le fond, et je con�ois sa r�ticence. Cependant, avant de forcer le transtypage � coups de reinterpret_cast< >, j'aimerais comprendre de quoi il retourne. Aussi me suis-je pench� sur le Livre Sacr�, qui dit � propos de ces types :

Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9); that is, they have the same object representation.
For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible
bit patterns of the value representation represent numbers.

Je ne comprends pas cette derni�re phrase. Quelqu'un pourrait-il m'expliquer �a, histoire que je devine comment traiter le probl�me ????????

[loufoque]

Tu t'en fous, caste.

[Jean-Marc.Bourguet]

j'ai un petit souci, d� au fait que le compilateur refuse de transtyper du const char* (qui m'arrive en entr�e) vers du const unsigned char*, ce dernier type �tant requis par une librairie que je dois utiliser.

Normal, ce sont des pointeurs vers des types diff�rents. Il n'y a pas de raisons pour laquelle ce devrait �tre permis.

Remarquez que je ne lui en veux pas, sur le fond, et je con�ois sa r�ticence. Cependant, avant de forcer le transtypage � coups de reinterpret_cast< >, j'aimerais comprendre de quoi il retourne. Aussi me suis-je pench� sur le Livre Sacr�, qui dit � propos de ces types :

Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9); that is, they have the same object representation.
For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible
bit patterns of the value representation represent numbers.

Je ne comprends pas cette derni�re phrase.

Pour comprendre, il faut savoir que si un type T occupe sizeof(T) bytes, la norme permet que d'une part certains bits ne participent pas � la valeur et d'autre part que certaines combinaisons des bits participants � la valeur soient interdites. Ce paragraphe dit que d'une part pour les 3 types caract�res (char, unsigned char et signed char), tous les bits participent � la valeur et d'autre part que pour unsigned char il n'y a pas de combinaisons interdites. Ce qu'on savait aussi par 3.9.1/4 qui impose pour les types non sign�s d'avoir 2^N valeurs o� N est le nombre de bits participant � la valeur (donc on sait aussi que pour unsigned char, il n'y a pas de combinaisons repr�sentant la m�me valeur). On n'a pas ces deux contraintes pour signed char qui donc peut avoir des valeurs interdites et des combinaisons synonymes.

Comme plus haut il est �crit que les 3 types ont la m�me taille et la contrainte d'alignment (en fait il ne peut pas y en avoir car size(char) == 1) tu peux faire un cast de char const* en unsigned char const* l'�me en paix. L'inverse est moins s�r s'il y a des valeurs interdites ou synonymes pour char. Les valeurs synonymes dans char, je ne vois pas d'architecture o� ce soit possible. Les valeurs interdites, en compl�ment � 1 ou en grandeur et signe, il peut �tre sens� d'interdire le -0.

[Herode]

Voil� qui est limpide. Merci pour ce petit cours 8)