Discussion :

[Invité]

Un type dont l'utilité m'échappe. Je m'explique.
Voyez ce tableau :

Vous aurez sûrement compris qu'il indique la taille des principaux types de C/C++ selon l'architecture du système d'exploitation.
Or on constate une chose : quand le type long long existe, soit le type long a la même taille qu'int, soit la même taille qu'un long long. C'est idiot ?
Si par exemple pour win64 et win32, short faisait 16 bits, int 32 et long 64, ce serait bien plus simple, non ? Eh ben, short fait 16 bits, int et long 32, et long long 64.
Du coup le type long seul ne sert à rien, il faut le doubler pour ne pas avoir la même chose qu'un int.

Il y a pas mal de chose qui me sont obscures en C/C++, mais là...il va falloir que quelqu'un m'éclaire.
Merci d'avance.

[koala01]

Salut,

En fait, tu poses la question pour le mauvais type : le type long long est le type primitif pour lequel il y a la garantie (ou peu s'en faut) qu'il sera composé de 64bits, alors que, comme l'indique le tableau, le type long pourra selon le cas représenter une donnée 32 bits ou une donnée 64 bits.

Par contre, ce qui est peut être intéressant, c'est de connaitre le pourquoi de cette différence

Ce qui se passe, c'est qu'il existe différentes architectures de processeurs. Certaines d'entre-elles étaient déjà des architectures 64bits bien longtemps avant l’engouement pour la chose qui est apparu au début des années 2000.

La norme a à l'origine prévu le type long pour ce genre d'architecture, à une époque ou l'on estimait (à tort) que 32bits seraient amplement suffisants pour représenter n'importe quelle valeur "justifiée". Il était donc "normal" que le type long soit codé sur 64 bits pour ces architectures et qu'il soit "limité" à 32 bits sur les architecture 32 bits

Par la suite, les architecture 64 bits se sont généralisées. Microsoft qui n'y croyait pas au début s'est d'ailleurs bien fait avoir et a du prolonger le support de XP le temps de fournir un OS 64 bits .

L'existence de nouvelles architectures, permettant l'utilisation de plus de bits pour représenter l'ensemble des données manipulées par le processeur, a forcément eu un impact au niveau des types primitifs : on ne pouvait pas "réutiliser" un type existant pour représenter ce nouveau type de données car cela aurait eu de l'influence sur toute la base de code existante. La décision de créer le type long long est justifiée par ce dernier point et fait que, oui, il est possible que long et long long représentent les données sous la forme d'un nombre identique de bits... ou pas. Mais long long te donne la "garantie" d'utiliser les 64 bits (alors que rien n'est sur pour le type long).

Notes enfin que le tableau est normalement purement informatif : la taille des types primitifs est implementation dependant, la norme se contentant de préciser que, dans la liste des types qu'est char, short, int, long et long long, chaque type est d'une taille au minimum suffisante pour permettre la représentation du type qui le précède dans la liste. Mais le nombre de bits par byte et le nombre de byte n'est défini absolument nulle part, ni dans la norme C, ni dans la norme C++

[white_tentacle]

En complément de la réponse de Koala, si tu souhaites maîtriser la taille de tes entiers (c’est le cas si tu travailles sur des grands entiers, par exemple), tu peux utiliser les types std::intXX_t

Cf http://en.cppreference.com/w/cpp/types/integer pour plus de détails (en anglais, malheureusement).

[Invité]

D'accord, merci pour ces précisions !
Cependant, heu...

le nombre de bits par byte [...] n'est défini absolument nulle part

Un byte, ce n'est pas un octet ? Ça contient toujours 8 bits, non ?

@white_tentacle
Je le savais déjà mais merci quand même


Autre question : si j'utilise un long long ou un std::int64_t et que j'essaie de faire tourner le programme sur une architecture 32 bits, ça va poser problème ?

[Médinoc]

Un byte, ce n'est pas un octet ? Ça contient toujours 8 bits, non ?

Un byte, c'est au moins un octet (du moins, en C et C++). CHAR_BIT est toujours au moins 8.

Autre question : si j'utilise un long long ou un std::int64_t et que j'essaie de faire tourner le programme sur une architecture 32 bits, ça va poser problème ?

Si ça compile, c'est que la plate-forme supporte le type. Par contre, sous une architecture 32 bits, tu ne peux pas stocker un int64_t dans un intptr_t.

[Invité]

Si un byte, c'est au moins un octet, comment on dit octet en anglais ? (c'est une vraie question)

[white_tentacle]

On dit octet aussi en anglais.

Sinon, attention à un point : la remarque de Médinoc concernant le byte qui fait au moins un octet n’est valable que dans le contexte de C/C++. Dans d’autres contextes, un byte peut faire par exemple 4, ou 7 bits…

Néanmoins, sur toutes les archis non esotériques, un byte fait maintenant 8 bits.

[Invité]

D'accord. Merci beaucoup pour toutes vos indications !

[bacelar]

Octet se traduit en byte.

C'est une longue histoire la taille d'un mot, d'une zone adressable ...
http://en.wikipedia.org/wiki/Word_(c..._architecture)

Un peu comme les petit et les gros boutiens

Ou l'arithmétique en complément à 1 ou à 2 ...

[Sve@r]

Mais le nombre de bits par byte et le nombre de byte n'est défini absolument nulle part, ni dans la norme C, ni dans la norme C++

Bonjour

N'y a-t-il pas quand-même un nombre "minimal imposé" style "un short fera toujours au-moins 16 bits" ???

[Médinoc]

Il me semble que c'est plus un détail d'implémentation, conséquence des maxima minimaux définis par la norme et du fait que les ordis d'aujourd'hui soient binaires, qu'une vraie règle de la norme.

Je ne sais plus si la norme oblige que les entiers soient codés en binaire (je sais qu'elle n'oblige pas que les flottants soient en IEEE 754). Sur un ordi ternaire, la taille minimale d'un unsigned short serait 11 trits.

[ternel]

la norme ne pose que quelques exigences: l'intervalle de valeurs minimal possible, et un rapport entre les tailles des types.

ainsi sizeof(char) ≤ sizeof(short) ≤ sizeof(int) ≤ sizeof(long)
et unsigned char doit pouvoir représenter l'intervalle [0; 255]

Il y a une implication directe du genre sizeof(short)≥16bits

[koala01]

la norme ne pose que quelques exigences: l'intervalle de valeurs minimal possible, et un rapport entre les tailles des types.

ainsi sizeof(char) ≤ sizeof(short) ≤ sizeof(int) ≤ sizeof(long)
et unsigned char doit pouvoir représenter l'intervalle [0; 255]

Il y a une implication directe du genre sizeof(short)≥16bits

Il n'y a aucune implication directe ou que ce soit, vu que sizeof(short) est plus grand ou égal à sizeof(char). Autrement dit, il serait tout à fait possible de trouver une implémentation dans laquelle la taille du short (et de tous les types potentiellement plus grands) serait égale à celle d'un char

Quant à l'intervalle minimal, je crois plutôt qu'il se situe dans la fourchette [0,127] car, à l'origine la table ASCII ne définit que les caractères dont les indices sont compris dans cet intervalle (avec 127 ou b1111111 comme symbole "delete"). J'ai d'ailleurs eu l'occasion de "jouer" avec des plaquettes de simulation dont les bytes étaient de 7 bits (bon, c'étaient des ancêtres, déjà quand je les ai vues, mais quand meme )

Or, l'intervalle [0,255] est spécifique à l'intervalle d'une valeur binaire codée sur 8 bits qui correspond à la table ASCII étendue et, comme par hasard (enfin pas si tant que cela ) à la taille du byte sur les architectures compatible IBM depuis les premiers processeurs du genre

[Médinoc]

IIRC, avec CHAR_BIT ayant un minimum de 8, de mémoire la norme dit [0; 127] pour char, [0; 255] pour unsigned char, et [-127; +127] pour signed char. Mais je n'ai pas vérifié, il est trop tard ce soir pour ça.

[koala01]

IIRC, avec CHAR_BIT ayant un minimum de 8, de mémoire la norme dit [0; 127] pour char, [0; 255] pour unsigned char, et [-127; +127] pour signed char. Mais je n'ai pas vérifié, il est trop tard ce soir pour ça.

Le problème est que CHAR_BIT est un symbole défini par le préprocesseur... Cela semblerait indiquer qu'il peut parfaitement valoir autre chose que 8 sur des architectures "exotiques".

Je n'ai pas la norme C sous la main pour vérifier, et donc, il y a peut être un point de cette dernière auquel je n'ai pas pensé, mais je suis sur qu'il n'y a aucune information de taille précisée dans la norme C++. Tout ce que l'on sait, c'est que sizeof(char) = 1 et que toutes les autres tailles doivent être un multiple de cette taille :S

Et puis, nous n'en avons pas encore, mais, qui sait si nous n'aurons pas un jour des processeurs utilisant UTF16 ou UTF32 (voir, pourquoi pas, iso8859-1) comme table de caractères "d'origine" ?

[gl]

Comme l'indique Médinoc, la plage pour un unsigned char est bien [0,255] et pour un signed char [-127,127]

— minimum value for an object of type signed char
SCHAR_MIN -127 // − (2⁷ − 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 2⁷ − 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 2⁸ − 1

Pour un plain char, les choses sont plus compliqué, le plain char pouvant être signé ou non selon l'implémentation la plage garantie est bien dans ce cas [0,127]

If the value of an object of type char is treated as a signed integer when used in an expression, the value of CHAR_MIN shall be the same as that of SCHAR_MIN and the value of CHAR_MAX shall be the same as that of SCHAR_MAX. Otherwise, the value of CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same as that of UCHAR_MAX. The value UCHAR_MAX shall equal 2^CHAR_BIT − 1.

Le problème est que CHAR_BIT est un symbole défini par le préprocesseur... Cela semblerait indiquer qu'il peut parfaitement valoir autre chose que 8 sur des architectures "exotiques".

IL peut parfaitement valoir autre chose que 8 mais pas moins (et c'est bien ce que disais Medinoc : "CHAR_BIT ayant un minimum de 8", ne serait-ce que pour respecter les plages garanties

Je n'ai pas la norme C sous la main pour vérifier, et donc, il y a peut être un point de cette dernière auquel je n'ai pas pensé, mais je suis sur qu'il n'y a aucune information de taille précisée dans la norme C++. Tout ce que l'on sait, c'est que sizeof(char) = 1 et que toutes les autres tailles doivent être un multiple de cette taille :S

Mais pour le coup, la norme C (et donc celle du C++ puisque sur climits, elle reprends le contenu de limits.h) précise belle et bien une valeur minimale de 8 pour CHAR_BIT :

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

[renoo]

la norme ne pose que quelques exigences: l'intervalle de valeurs minimal possible, et un rapport entre les tailles des types.

ainsi sizeof(char) ≤ sizeof(short) ≤ sizeof(int) ≤ sizeof(long)
et unsigned char doit pouvoir représenter l'intervalle [0; 255]

Il y a une implication directe du genre sizeof(short)≥16bits

short fait au moins 16bits, long fait au moins 32bits, long long au moins 64 bits. http://en.wikipedia.org/wiki/C_data_types#Size

[koala01]

short fait au moins 16bits, long fait au moins 32bits, long long au moins 64 bits. http://en.wikipedia.org/wiki/C_data_types#Size

Non, ça, ce sont les tailles couramment constatées sur la majorité des architecture. Mais, sauf erreur de ma part, même la norme C n'impose rien d'autre qu'une relation de taille entre les différents types primitifs qui font que short est au minimum plus grand ou égal à char et que int est au minimum plus grand ou égal à short (et ainsi de suite).

Bien sur, on peut arguer du fait que les principales architectures respectent les tailles citées par wikipedia pour estimer que "ce sont les tailles que l'on rencontrera généralement", mais, il n'empêche que tu risque toujours de te retrouver face à une architecture plus "exotique" sur laquelle ces assertions s'avéreront fausses.

C'est comme de dire qu'un pointeur est d'office représenté sous la forme d'un (unsigned) int. C'était vraisemblablement vrai à une époque (en gros, avant que les architectures 64 bits ne soient utilisées pour les PC), mais ce n'est pas forcément vrai. Et c'est la raison pour laquelle la norme défini le type ptr_t comme étant l'alias du type entier non signé capable de représenter n'importe quelle adresse mémoire accessible.

Et je pourrais faire le parallèle avec bien d'autres types de valeurs pour lesquelles l'intervalle de valeurs dépend essentiellement de l'architecture et du système d'exploitation

[gl]

Mais, sauf erreur de ma part, même la norme C n'impose rien d'autre qu'une relation de taille entre les différents types primitifs qui font que short est au minimum plus grand ou égal à char et que int est au minimum plus grand ou égal à short (et ainsi de suite).

Elle impose également des plages de valeurs représentables. Plages à partir desquelles on peut déduire des tailles minimales

[Invité]

Ouais, je me souviens d'un tableau durant mes cours de C donnant les tailles minimales de char, int et long, et c'étaient bien celles données par renoo.