Discussion :

[joffrey575]

Bonjour à tous,

En ce moment j'essaie de connaitre la taille des types comme int, double, ... avec un processeur 16, 32 (ou 64 bits).

Est-ce que le tableau suivant est correcte (ce tableau est valable sur le site comment ça marche pour le C++) ? Je remarque que seulement les entiers changent avec 16 ou 32 bits mais les doubles et les floats restent à la meme taille, ...



Je ne sais pas sur quel base partir pour calculer la taille des types en C.

----------

Également, j'aimerais parler du cast. Sur les lignes de code ci-dessous, pourquoi on a (char*) et pas (char).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
int main()
{
float a=3.14;
char *j;
j = (char*)&a;
printf("%d\n", *j);
return 0;
}

Voila, merci à vous

[Obsidian]

Bonjour,

En ce moment j'essaie de connaitre la taille des types comme int, double, ... avec un processeur 16, 32 (ou 64 bits).

Est-ce que le tableau suivant est correcte (ce tableau est valable sur le site comment ça marche pour le C++) ? Je remarque que seulement les entiers changent avec 16 ou 32 bits mais les doubles et les floats restent à la meme taille, ...

Ça a l'air valable à première vue.

En fait, en langage C, les types entiers proposés sont faits pour correspondre à peu près aux usages en vigueur dans la discipline, mais il garantissent surtout une largeur minimale. Ils ne seront jamais plus restreints, mais peuvent être plus larges selon la plateforme utilisée. Cela est dû au fait que la plateforme cible peut ne pas prendre nativement en charge les formats concernés, mais également parce qu'elle peut aussi ne pas travailler au niveau de l'octet !

Certaines architectures manipulent, par exemple, des mots de 32 de bits directement, avec une adresse propre. Il est possible (mais pas obligatoire) que sur ces machines, tous les entiers, char, short, long… soient en pratique tous ramenés au même format.

En outre, certaines architectures ne travaillent pas non plus au niveau de l'octet, ni avec des mots d'une largeur multiple de 8 bits (exemple : certains PIC basés sur des mots de 12 bits). Dans ce cas, il est plus que probable que le type le plus proche soit directement ramené à ce format natif plutôt que tronqué artificiellement par des moyens logiciels et sans raison concrète.

Pour cela, d'ailleurs, l'unité de taille définie par la norme est le « char », qui vaut toujours 1 par convention.

Il existe la macro CHAR_BIT pour savoir exactement à combien de bits correspond 1 char. Un char est un entier suffisamment grand pour contenir les 91 caractères du jeu standard défini par la norme. La plupart du temps, ce sera 8 parce qu'il faut déjà au moins sept bits pour représenter les 91 caractères, plus éventuellement un bit de signe dans le cas des char signés, puisque les caractères eux-mêmes sont forcément positifs ou nuls. Donc un char fait forcément huit bits au minimum, ce qui tombe sur l'octet, qui est le format quasi-universellement adopté aujourd'hui dans l'industrie. C'est pourquoi on a coutume de penser que « 1 char = 1 octet » : c'est généralement vrai en pratique et c'est ce qui est utilisé partout ailleurs même en dehors du langage C, mais sur une architecture 12 bits par exemple, il y a de fortes chances qu'un char = douze bits…

Si la largeur des entiers est importante pour toi, tu peux ajouter #include <stdint.h> pour bénéficier d'entiers à la taille garantie telle que uint32_t. Il s'agit en fait de typedef vers les types natifs du C, ce qui signifie que contrairement ces types natifs qui sont toujours disponibles mais dont la taille peut varier sur des architectures exotiques, la taille de ces entiers-là
sera toujours garantie mais les entiers eux-mêmes pourront ne pas être disponibles.

Les nombres en virgule flottante utilisés par le C, par contre, sont des formats normalisés par IEEE 754. Leur taille est donc forcément toujours la même, tout comme la manière de représenter les nombres eux-mêmes à l'intérieur du champ de bits. C'est extérieur à la norme C. Si l'architecture-cible n'est pas capable de les prendre en charge, alors c'est la bibliothèque C qui le fera logiciellement. Aujourd'hui, toutes les machines grand public sont équipées d'un coprocesseur mathématique, et celui-ci est intégré de longue date au micro-processeur lui-même, mais pendant très longtemps (jusqu'au 486 sur PC), ces machines n'en étaient pas équipées du tout par défaut.

Je ne sais pas sur quel base partir pour calculer la taille des types en C.

Comme dit plus haut, « sizeof (type)» pour connaître la taille d'un type en nombre de char (qui équivaudra souvent à un nombre d'octet), puis la macro CHAR_BIT issue de limits.h pour connaître le nombre de bits dans un char (généralement 8).

Également, j'aimerais parler du cast. Sur les lignes de code ci-dessous, pourquoi on a (char*) et pas (char).

Parce que « char * » est un « pointeur sur un char », c'est-à-dire qu'il contient l'adresse en mémoire d'un caractère (ou du début d'une série de caractères dans le cas d'une chaîne). En l'occurrence, c'est l'adresse de a, obtenue avec le préfixe « & ». Il se trouve que a n'est pas un char mais un float, d'où la nécessité du transtypage explicite. Ce programme est visiblement fait non pas pour lire le contenu de la mémoire comme des caractères mais pour décomposer octet par octet le contenu d'un float pour montrer comment il est construit.