bonjour,
impossible de trouver la specification C en ligne,
uniquement a telecharger pour 18$.
tous ca, juste pour une petite question sur la taille des types.
journal, est-il bien vrai qu'en C la seule garantie est que char fait 8 bits, et que int ou short int sont plus grand.
si oui, est ce que c'est >= ou > :
sizeof(short int) >= 2 ou
sizeof(short int) > 2
tout ca juste pour coder un truc qui utilise des sequances de 16 bits
(je sais qu'avec gcc, il suffit d'utiliser un short, mais je voudrais un truc dont on est absolument certain qur ca marchera sur toute les machines qui ont un compilateur c99, meme les plus tordue)
Journal c ansi
1
juil.
2003
# Re: c ansi
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 10.
# Re: c ansi
Posté par Loic Jaquemet . Évalué à 2.
short == deux octets
short <= int <= double
int sur processeur 32 bits == 4 octets
long int == int
double = 8
sinon ya des typedef du genre u16, u32 ... un truc du genre ...
[^] # Re: c ansi
Posté par Obsidian . Évalué à 6.
short <= int <= double
Un double est un nombre en virgule flottante ! c'est donc un float avec une mantisse étendue. A ne surtout pas comparer avec les entiers ...
Bon sinon, la taille d'un int seule est fonction de l'architecture de ta machine, donc 2 octets (comme un short) sur une machine 16 bits, 4 octets (comme un long) sur une machine 32 bits. C'est fait exprès. Cela correspond en général à la taille d'un registre du processeur (le plus souvent l'accumulateur).
char correspond à la taille d'un caractère. Depuis l'ASCII, on code les caractères sur 8 bits, mais si tu tombes sur une machine qui utilise l'Unicode en natif (une telle machine n'existe pas à ma connaissance), tu peux te retrouver avec un char=2 octets.
La taille des types de données natifs sera probablement réajustée avec le passage à 64 bits mais bon pour faire simple, disons que dans 99,99% des cas:
char = 1 octet
short int = 2 octets
int = 4 octets (car archi 32 bits le plus souvent)
long int = 4 octets
float = 4 octets
double = 8 octets
pour avoir des entiers très longs, il me semble que c'est "long long" (8 octets) ou "quad" (pareil), mais c'est à vérifier.
Enfin, s'il est vraiment vital pour toi de préciser impérieusement la longueur de ces données pour toutes les machines existant sur Terre et à venir (mais tournant sous Unix), jète un oeil aux fichiers types.h et sys/types.h, ils contiennent les définitions des types u_int8, u_int16 etc. qui en principe devraient toujours correspondre aux longueurs demandées.
Amuse-toi bien.
[^] # Re: c ansi
Posté par Edouard Gomez (site web personnel) . Évalué à 4.
La norme ANSI C (aka ISOC89) ne prévoit pas de types entiers de 64bit. Par contre il est vrai que la norme ISOC99 fixe un "long long" comme étant un type entier de 64bit.
Le terme "quad" m'évoque bien plus l'assembleur IA32 ou effectivement on y cotoie des "quad word" pour le MMX (instructions post/prefixées par "q" ou "p", movq, por, pand, pmul, padd pour indiquer que ca travaille sur les registres MMX 128bit).
# Re: c ansi
Posté par Anonyme . Évalué à 1.
cherche aussi n869.pdf et n2794.pdf
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/(...) est
browsable.
c'est pas le C ansi, c'est juste un draft.
Mais bon, on fait avec :)
un char fait *au moins* 8 bits, c'est tout ce qu'on sait.
Ca peut faire plus.
d'autre part sizeof(char) = 1
quelle que soit la taille reelle en octets du char
sur la machine.
p 70 de la doc pour le sizeof
pp. 18 et 19 sinon pour le short.
short c'est au moins entre -32767 et 32767, peut-etre plus.
la meme chose pour int.
pour tes sequences de 16 bits, utilise un short. Si
ca plante qqpart tu verras a ce moment. (a mon avis)
(apres ca depend ce que tu veux faire avec ta
sequence)
[^] # Re: c ansi
Posté par Anonyme . Évalué à 1.
[^] # Re: c ansi
Posté par edouard boucher . Évalué à 1.
et pour ca je ne sais pas trop quoi utiliser, si aucune taille n'est garantit, parceque la, la tailel est importante.
dans tout les exemples que je vois, c'est a base de char ou short,
mais ca me parait incorect non ?
# Re: c ansi
Posté par Nap . Évalué à 0.
--->[-1]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.