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)

[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

[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