char - Page 1

re-hello !
j'ai besoin de la commande char() en basic, càd obtenir un caractère à partir du code ASCII
ce n'est pas pour printf() que j'en ai besoin
et puis c'est pour GTC aussi ^^
merci

int prout;
char waaargh;
waaargh=(char)prout;

De rien ^^

aussi simple que ça ? merci ^^

Il n'y a pas en C de type de caractère avec des fonction particulières. En fait char est juste une variable sur un octet (-128 à 127) qui contient le code ascii du caractère.

oui mais non, les constantes caractères sont curieusement signées (jamais capté pkoi)

Martial Demolins (./5) :
donc plutôt 0-255 dans ce cas-là.

Et bien non. Et ce n'est pas si contradictoire que ça vu que l'ASCII standard c'est du 7 bit.
Si tu veux du 0-255 il te faut un "unsigned char".

Sans doute une relique des débuts du langage C. D'ailleur les chaînes de caractères sont passées en char * pas en unsigned char *.

geogeo (./9) :
D'ailleur les chaînes de caractères sont passées en char * pas en unsigned char *.

Bah c'est juste une implication du fait qu'un char represente un caractere...

Martial Demolins (./8) :
euh... si je me trompe pas, on est sur un forum TI, pour les quelles le code ASCII utilisé est étendu à 255... bref, je prétends pas te l'apprendre, mais ça me semble plus adapté ici, c'est tout.

et toi non plus, tu ne m'as pas appris qu'un caractère ascii non-étendu est codé sur 7 bits...

Certes mais on parles de C et même sur un forum TI, le C reste du C avec ces héritages des temps anciens de l'informatique ou les extensions à l'ASCII n'étaient ni standardisées ni courantes.

De toute façon, que l'on utilise des char signés ou non pour stoquer des caractères, ça ne pose aucun problème, même pour l'ASCII étendu.
Les additions, and et or, fonctionneront tout de même et quel esprit tordu aurait l'idée de faire des multiplications ou autre sur des caractères?

En fait si ça pose quand même un problème maintenant que j'y pense vu que avec un char on devrait avoir 'é' < 'e' au lieu de 'é' > 'e' avec un unsigned char.

Je n'ai jamais compris pourquoi les caractères normaux étaient signés...

c'est juste que tout les types de bases sont signé...

ben char est pas forcément signé justement, c'est spécifique à chaque plateforme...

oula, c'est meme pire... char n'a meme pas une taille fixe... "il doit permetre de stoquer les caracteres"

bref en gros une machine qui permet d'avoir que 64 caracteres pourrait avoir un char 6bits

Je comprends pas qu'on utilise pas plus les types s8, s16, ... et u8, u16. C'est beaucoup plus clair, je me fais toujours des typedef pour ça.

oui mais c'est pas forcément les types les plus efficaces... par exemple sur x86 un s32 est plus rapide qu'un s16, d'où l'intérêt de définir 'int' comme étant le plus efficace des types de plus de 16 bits ^^

et puis il y a d'autres facteurs, par exemple size_t permet d'adapter la précision des pointeurs à la capacité mémoire de la plateforme : sur une plateforme 16 bits, on peut se contenter de stocker une longueur sur 16 bits, alors que sur une plateforme 64 bits on va avoir besoin de 64 bits...

Godzil (./16) :
oula, c'est meme pire... char n'a meme pas une taille fixe... "il doit permetre de stoquer les caracteres"

bref en gros une machine qui permet d'avoir que 64 caracteres pourrait avoir un char 6bits

je crois pas, en principe ils font 8 bits minimum ^^

Pollux (./18) :
oui mais c'est pas forcément les types les plus efficaces... par exemple sur x86 un s32 est plus rapide qu'un s16, d'où l'intérêt de définir 'int' comme étant le plus efficace des types de plus de 16 bits ^^

ah oui ok j'avais pas pensé à ça

Pollux (./18) :
et puis il y a d'autres facteurs, par exemple size_t permet d'adapter la précision des pointeurs à la capacité mémoire de la plateforme : sur une plateforme 16 bits, on peut se contenter de stocker une longueur sur 16 bits, alors que sur une plateforme 64 bits on va avoir besoin de 64 bits...

oui pour le size_t je suis d'accord, je l'utilise

Pollux (./18) :
oui mais c'est pas forcément les types les plus efficaces... par exemple sur x86 un s32 est plus rapide qu'un s16, d'où l'intérêt de définir 'int' comme étant le plus efficace des types de plus de 16 bits ^^

et puis il y a d'autres facteurs, par exemple size_t permet d'adapter la précision des pointeurs à la capacité mémoire de la plateforme : sur une plateforme 16 bits, on peut se contenter de stocker une longueur sur 16 bits, alors que sur une plateforme 64 bits on va avoir besoin de 64 bits...

Godzil (./16) :
oula, c'est meme pire... char n'a meme pas une taille fixe... "il doit permetre de stoquer les caracteres"

bref en gros une machine qui permet d'avoir que 64 caracteres pourrait avoir un char 6bits

je crois pas, en principe ils font 8 bits minimum ^^

Dans la réalitée pitet, mais c'est ce qui est ecrit dans la norme C90

Martial & Godzil> absolument pas, C90 précise que les char doivent faire au moins 8 bits :

Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

— number of bits for smallest object that is not a bit-field (byte)

CHAR_BIT 8

— minimum value for an object of type signed char

SCHAR_MIN -127 // -(2^7-1)

— maximum value for an object of type signed char

SCHAR_MAX +127 // 2^7-1

— maximum value for an object of type unsigned char

UCHAR_MAX 255 // 2^8-1

— minimum value for an object of type char

CHAR_MIN see below

— maximum value for an object of type char

CHAR_MAX see below
... et etc pour les short, les long ...

donc si une architecture manipule des paquets de 7 bits, pour respecter la norme elle devrait les regrouper pour avoir des char de 14 bits (ou plus)

Définition du C90 (repris du K&R seconde edition)

Chapitre 2.2:

char: un seul octet, pouvant contenir un caractère du jeu de caractères de la machine utilisé.
[...]
Ainsi, par exemple, si les chars sont représenté sur 8 bits, les variables de type unsigned char peuvent prendre les valeurs de 0 à 255...

Chapitre A4.2:

Les objets déclaré comme caractères (char) sont assez grand pour mémoriser n'importe quel élément du jeu de caractère d'éxécution. Si l'on stocke réellement un caractère de ce jeu dans un objet de type char, sa valeur est celle de l'entier qui code ce caractère, et elle est positive ou nulle. On peut stocker d'autres quantités dans des variables de type char, mais c'est l'implémentation qui détermine quelles sont les valeurs possibles, et surtout le fait que ces valeurs soit signées ou non.

et... ?

c'est pas parce que les char peuvent représenter n'importe quel caractère qu'ils ont le droit de faire moins de 8 bits, hein la clause A4.2 n'est là que pour éviter que 'A' = 870 sur une plateforme où les chars font seulement 9 bits...

Et "un seul octet" ça me semble assez clair quant à la taille de la donnée non ?

un octet ne fait pas forcément 8 bits :

byte: addressable unit of data storage large enough to hold any member of the basic character set of the execution environment

(en fait c'est la traduction qui rajoute une imprécision, en anglais il y a le mot "octet" pour dire un "byte" de 8 bits, alors que "byte" ne dit rien sur la taille)