Discussion :

[doccpu]

Petite remarque, le standard c++ dicte cette regle sur la longueur des types: char <= short <= int <= long. Ce qui implique que cela risque de pouvoir varier d'un compilateur a l'autre. Sur 32 bit, la regle etait suivie (8, 16, 32, 32). Sur 64 bit aussi, mais peut etre certains compilateurs implanteront int = long = 64) Encore une fois, utilisez climits[/code]

Bon, je dis ca de souvenir, il y a surement d'autre details importants

Cela m'ettonne que le long soit éttendu alors que depuis le debut de l'informatique c'est l'int qui a servit de pointeur (int = taille du bus d'adresse). Le long a toujours quant a lui été calculé sur 32 bits (sur les machines 16 bits aussi) et le long long sur 64 (sur les machines 32 bits aussi)

Quant a la regle (char <= short <= int <= long) elle n'est pas tout a fait exacte car en fait c'est :
[unsigned] char = 8 bits, [unsigned] short = 2 char, [unsigned] long = 2 short, [unsigned] long long = 2 long, int = taille du bus d'adresses,
pour les entiers et :
[unsigned] single = 32 bits, [unsigned] double = 2 single, float = taille du bus d'adresses.
pour les flottants.

Jusque à present l'apparence conservait : char < short <= int <= long < long long, mais je ne pense pas que cela reste ainsi. Enfin comme vous l'avez dit ce ne sont que des valeurs arbitraires, basées sur les types physiques du processeur, mais ce ne sont que des conventions.

Vous pouvez retrouver les types processeurs sur :
www.sandpile.org

A++ et bon Trolls (de Troy, biensur )

[loufoque]

Quant a la regle (char <= short <= int <= long) elle n'est pas tout a fait exacte car en fait c'est :
[unsigned] char = 8 bits, [unsigned] short = 2 char, [unsigned] long = 2 short, [unsigned] long long = 2 long, int = taille du bus d'adresses,
pour les entiers et :
[unsigned] single = 32 bits, [unsigned] double = 2 single, float = taille du bus d'adresses.
pour les flottants.

C'est totalement faux.
Le standard ne dit rien de tel.

Il dit d'abord que sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long).
Ensuite une lecture plus fine permet de voir qu'un char fait au moins 8 bits, un short au moins 16 bits, un int au moins 16 bits, et un long au moins 32 bits.

Et c'est tout.
On peut très bien avoir sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) avec des bytes de 32 bits. C'est d'ailleurs le cas sur les DSP.

[Luc Hermitte]

Et sur solaris, j'ai des long de 64bits, tout comme les long long.

[doccpu]

C'est totalement faux.
Le standard ne dit rien de tel......

alors essaie de porter un programme qui a été developpé avec de grande valeur long et int en 32 voir 64 bit et porte les sur un système embarqué 16bit bit et pleure sur l'int car c'est lui qui fera 16bit alor que le long lui restera a 32 bit. tu peux essayer de le passer sur un système 8 bit mais je garanti pas que le long existe sur de tels systèmes mais la encore l'int fait 8bit (CQFD : int = largeur du bus d'adresses)

quant a la taille du char elle fait 8 bit parce que les registres du processeur ne savent pas gerer des donnees < 8bit. C'est ce qui determine aussi les alignements de donnees en memoire centrales.

[Matthieu Brucher]

alors essaie de porter un programme qui a été developpé avec de grande valeur long et int en 32 voir 64 bit et porte les sur un système embarqué 16bit bit et pleure sur l'int car c'est lui qui fera 16bit alor que le long lui restera a 32 bit. tu peux essayer de le passer sur un système 8 bit mais je garanti pas que le long existe sur de tels systèmes mais la encore l'int fait 8bit (CQFD : int = largeur du bus d'adresses)

Si tu relis bien ce que loufoque a écrit, tu ne le contredis pas, en revanche, lui oui.

[doccpu]

Si tu relis bien ce que loufoque a écrit, tu ne le contredis pas, en revanche, lui oui.

quesce qui calcule si ce n'est le processeur ?
la norme est entierrement basée sur lui et si vous voulez plus de detail alez voir le lien que j'ai donné plus haut !
et si je le contredit en disant que int = taille bus d'adresse !

[Matthieu Brucher]

Bon, un exemple qui montre que ça ne marche pas exactement comme tu le dis. On prend un processeur capable de fonctionner en 32 bits et en 64bits. En interne, c'est une seule largeur de bus unique et pourtant un int peut valoir 32bits ou 64bits.

[doccpu]

Bon, un exemple qui montre que ça ne marche pas exactement comme tu le dis. On prend un processeur capable de fonctionner en 32 bits et en 64bits. En interne, c'est une seule largeur de bus unique et pourtant un int peut valoir 32bits ou 64bits.

comme tu l'a dit c'est un processeur capable de fonctionner en 32 ou 64 bit.

en mode 32 il aura un bus d'adresse de 32bit et en 64 il aura un bus d'adresse de 64 bit

essaye d'acceder a la memoire au dela des 32 bits en mode 32 bit et ca te fera bizare (a moins qu'en interne ton processeur passe en mode 64 bit pour acceder a la memoire)

n'oublion pas la compatibilité ascendante (qui peut le plus peux le moins)

et ca ne contredit pas ce que j'affirme sur le fait que tu peux metre 2^64 valeurs dans un "int" en mode 64bit alors que tu ne peux pas le faire dans un "long" (qui est limité a 2^32 valeurs) dans ce meme mode. Pour pouvoir utiliser 2^64 valeur avec des types fixes il faut utiliser "long long"

donc ce que je disait a propos de l'int (int = taille du bus d'adresse) est toujours valide(en mode 32 il fait 32, en mode 64 il fait 64)

[Matthieu Brucher]

Un long sur une archi 64bits peut valoir 64bits, je vient de faire le test.
Le choix de la taille d'un type est puremet laissée au choix du concepteur du compilateur.

Ah oui, depuis le Pentium pro, le bus d'adresse fait en 36bits.

[nicroman]

en mode 32 il aura un bus d'adresse de 32bit et en 64 il aura un bus d'adresse de 64 bit
essaye d'acceder a la memoire au dela des 32 bits en mode 32 bit et ca te fera bizare (a moins qu'en interne ton processeur passe en mode 64 bit pour acceder a la memoire)
[...]
donc ce que je disait a propos de l'int (int = taille du bus d'adresse) est toujours valide(en mode 32 il fait 32, en mode 64 il fait 64)

Désolé d'intervenir, mais c'est complètement faux... ca fait très longtemps que les registres ALU des processeurs ne correspondent ni à la taille du bus d'addressage, ni à celle du bus de donnée !
Certains processeurs peuvent utiliser un bus de données de 128 bits, un bus d'addressage de 64 bits, et des registres internes de 32 bits !

Le Pentium-Pro avait un bus d'addressage 36 bits.
Le 68000 avait un bus d'addressage de 24 bits, un bus de donnée de 32 bits et des registres internes de 16 bits !
L'Itanium-64 propose int=32, long=64 et pourtant un addressage 64 bits si je ne m'abuse (ca fait longtemps que j'utilise plus int sauf pour des boucles simples aussi).

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) est vériatablement la seule chose dont on soit sur !
Après libre à chaque compilateur / profile-de-compilation de choisir les bonnes tailles.
C'est bien pour cette raison que pratiquement tous (si ce n'est tous) les compilateurs ont introduit des types de longeur fixe (__int8 sous VC++ par exemple).

Et loufoque a parfaitement raison... rien n'empeche de trouver un compilo avec tous les types qui font 32 bits !

size_t est le seul type qui soit assuré de pouvoir contenir tout l'espace d'addressage.

[loufoque]

C'est bien pour cette raison que pratiquement tous (si ce n'est tous) les compilateurs ont introduit des types de longeur fixe (__int8 sous VC++ par exemple).

int8_t etc. font partie du standard C99.
Et aussi de C++0x.

donc ce que je disait a propos de l'int (int = taille du bus d'adresse) est toujours valide(en mode 32 il fait 32, en mode 64 il fait 64)

Ce que tu ne sembles pas comprendre, c'est que le standard n'a aucune notion de "taille du bus d'adresse".
Les seules et uniques restrictions sur les tailles, je te les ai données. Le reste, c'est des détails d'implémentation.

[Jean-Marc.Bourguet]

tu peux essayer de le passer sur un système 8 bit mais je garanti pas que le long existe sur de tels systèmes mais la encore l'int fait 8bit

Une implémentation conforme a un int qui fait au moins 16 bits.

(CQFD : int = largeur du bus d'adresses)

Je ne vois aucune raison de fixer la taille d'un int en fonction de celle du bus d'adresse. (Au fait, les processeurs 8 bits ont généralement un bus d'adresse sur 16 bits)

quant a la taille du char elle fait 8 bit parce que les registres du processeur ne savent pas gerer des donnees < 8bit.

Un char fait au moins 8 bits. J'ai déjà utilisé une implémentation du C avec un char de 9 bits, des short de 18 bits et des int (et des long) de 36.

C'est ce qui determine aussi les alignements de donnees en memoire centrales.

Les contraintes d'alignement sont généralement le plus petit entre la taille de la donnée à transférer et la taille du bus de donnée.

[Jean-Marc.Bourguet]

quesce qui calcule si ce n'est le processeur ?

Et?

la norme est entierrement basée sur lui et si vous voulez plus de detail alez voir le lien que j'ai donné plus haut !

Ton lien ne concerne que les processeurs x86. Et la norme j'en ai un exemplaire, je sais ce qu'elle dit. Le choix est une conséquence de l'histoire du C, développé au départ sur un processeur 16 bits puis utilisé sur des processeur 36 et 32 bits. Tout cela bien avant que la famille x86 soit un facteur dans son évolution. L'article de Mashey vers lequel j'ai donné un lien est bien plus intéressant.

et si je le contredit en disant que int = taille bus d'adresse !

Les machines avec un int de 36 bits auxquelles je faisais allusion avait un bus d'adresse de 18 bits.

[Jean-Marc.Bourguet]

Le 68000 avait un bus d'addressage de 24 bits, un bus de donnée de 32 bits et des registres internes de 16 bits !

De mémoire, le 68000 avait des registres de 32 bits, mais un datapath de 16 bits.

size_t est le seul type qui soit assuré de pouvoir contenir tout l'espace d'addressage.

Non. void* est ce type. size_t peut être plus petit (sur une architecture segmentée comme le x86 en mode réel par exemple, size_t peut être sur 16 bits mais les pointeurs sur 32 bits -- avec seulement 20 bits efficaces), size_t est le type capable de contenir les tailles de tous les objets.

[nicroman]

Non. void* est ce type. size_t peut être plus petit (sur une architecture segmentée comme le x86 en mode réel par exemple, size_t peut être sur 16 bits mais les pointeurs sur 32 bits -- avec seulement 20 bits efficaces), size_t est le type capable de contenir les tailles de tous les objets.

Oui, c'est vrai... je me suis fourvoyé dans mes explications
Au temps pour moi !

[doccpu]

Ton lien ne concerne que les processeurs x86.

Et ?

Et la norme j'en ai un exemplaire, je sais ce qu'elle dit. Le choix est une conséquence de l'histoire du C, développé au départ sur un processeur 16 bits puis utilisé sur des processeur 36 et 32 bits. Les machines avec un int de 36 bits auxquelles je faisais allusion avait un bus d'adresse de 18 bits.

bon très bien je comprend mieux pourquois les programmes plantent. C'est clair que si les compilo font ce qu'ils veullent d'un processeur a l'autre...
Donc il faudrais peut etre voir a reviser le sois disant "standard" qui ne l'est pas puisqu'il n'y a alors plus de taille fixe (a par peut etre le char (8bit)). Je suis dans le traitement de signal audio et si la norme est telle que vous la decrivez je ne pourais jamais passer en 64bit puisque nous on travaille sur des long de 32 bit, et que si ce parametre change d'une implementation a l'autre on aura des tailles d'echantillons variables d'un processeur a l'autre on vas avoir des surprises en mode 64 bit dans le traitement.

Bonne réforme....

et desolé d'avoir trollé mais le standard est lui même trop laid !

Le jour ou j'apprend l'assembleur je refais tout les standards et l'informatique sera beaucoup plus stable !

[Matthieu Brucher]

C'est pour ça qu'il y a les types autres genre int8, ...
Et un char ne vaut pas forcément 8bts non plus.

[JolyLoic]

C'est justement pour assurer une portabilité que les tailles des différents types peuvent varier d'un compilateur à l'autre, d'un environnement à l'autre.

Ce qui n'empêche pas d'avoir besoin ponctuellement de types de taille déterminée, par exemple quand il s'agit d'inter-opérer dans un format binaire avec un autre programme.

[doccpu]

C'est pour ça qu'il y a les types autres genre int8, ...
Et un char ne vaut pas forcément 8bts non plus.

donc si je fais

Code :

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

char* c = new char[x];

je n'obtiendrais pas 8 * x bits dans mon tableau ?

ça promet!

C'est décidé, j'apprend l'assembleur !

[JolyLoic]

Tu peux avoir une garantie supplémentaire, fournie par ton environnement, qui t'assure que ça prend 8*x bits. Ou toute autre valeur * x bits. Le C ou le C++ en eux même ne garantissent rien là dessus. Si tu compiles ton code sur une autre architecture, il se peux que ça change.

Maintenant, si tu bosses en assembleur, tu n'as aucune portabilité, donc la question ne se pose pas.