Version imprimable
Dans ce deuxième article sur le C++ bas niveau, Alex Darby aborde les types de données et leurs représentations internes.
Programme d'étude sur le C++ bas niveau n° 2 : les types de données
:fleche: Quels sont les points les plus importants pour vous à connaître sur les types ?
:fleche: Connaissez-vous d'autres subtilités sur les types de données ?
Bonne lecture.
Retrouver l'ensemble des articles de cette série sur la page d'index.
Bonjour,
Merci pour cette article.
Cependant, le format PDF et autres ne sont téléchargeable.
Merci de procéder aux modifications nécessaires
A+
Merci pour l'article mais petite remarque sur la forme.Citation:
Enfin, j'ai pensé que je pourrais insérer ici quelques points-clés :
1.Presque tous les CPU ont des octets de 8 bits. Tout CPU avec plus de 8 bits par octet a probablement été créé par un maniaque/génie (N.B : J'ai remarqué qu'il y avait une différence particulièrement floue entre les deux en informatique).
Il me semble que le terme octet signifie 8 bits donc octet > 8 est impossible. AMHA le terme "information codée sur" xx bits conviendrait mieux.
@seabs
Merci, c'est corrigé
@giltt
En effet, c'est un abus de langage que d'assimiler octet et byte, un octet faisant toujours 8 bits, ce qui n'est pas le cas des bytes. Comme pour les cpu "classiques", c'est pareil, on traduit souvent byte par octet, mais dans le contexte, c'est effectivement incorrecte. J'ai corrigé l'article pour utiliser byte partout
Bonjour,
Bon article mais j'ai tiqué sur un point :
.Citation:
char fait au moins 8 bits
Il me semblait que les tous premiers char étaient sur moins de 8 bits et qu'en embarqué on peut parfois se trouver avec des char de 6-7 bits.
@Neckara:Selon la norme du C++, sizeof(char)=1, l'unité du résultat de sizeof est le byte. Or la définition du byte par la norme du C++ implique qu'il doit pouvoir (entre autre) représenter un codet UTF-8, donc au moins 8 bits.Voir messages suivants.
Les premiers jeux de caractères utilisés sur les ordinateurs étaient codés sur 6 bits. C'est rapidement paru insuffisant et on est passé à 8. ASCII, qui ne se voulait pas un jeu d'utilisation interne mais un jeu d'échange, était sur 7 bits pour au moins deux raisons. 1/ un médium d'échange courant à l'époque était les rubans perforés qui ne permettaient pas plus (ils ont 8 bits par ligne, mais sont tellement peu fiable qu'un bit de parité est indispensable). 2/ ils n'avaient pas matière à standardiser plus. EBCDIC conçu en même temps est sur 8 bits.Citation:
Envoyé par Neckara
J'en doute.Citation:
et qu'en embarqué on peut parfois se trouver avec des char de 6-7 bits.
Le char en C et en C++ fait au moins 8 bits depuis toujours(*), et ça date d'avant la conception même d'UTF-8.Citation:
Envoyé par Flob90
(*) Il y a eu des implémentations ayant des modes non conformes sur ce point pour des raisons d'interopérabilité avec le système, mais celle que je connais avait un mode conforme (avec des bytes sur 9 bits).
@Jean-Marc.Bourguet: En effet, j'ai oublié que la norme C++ inclut (entre autre) celle du C en ce qui concerne climits, et qui fixe le nombre minimum de bits à 8. Autant pour moi.
"Aussi loin que je l'ai découvert, les standards C et C++ ne donnent aucune garantie sur les tailles des types de base."
Le C99 à amené les types UintXX_t qui sont soit Unsigned soit signed, et sont codés sur exactement XX bits.
Dans le même genre, il y a ceux qui ont au moins XX bits, et ceux qui sont optimisés.
J'ai très vite pris le "int" de base en horreur, et quand j'ai découvert ces types, j'en suis tombé amoureux: quoi de mieux pour faire un programme portable que de connaître la portée réelle des types? Puisque, comme dis dans l'article, les types habituels n'ont absolument aucune fiabilité en terme de taille, et donc de plage de valeurs (le "int" est une excellente preuve d'ailleurs: on a soit un mot, soit un double mot, selon qu'on soit en 16 ou 32 bits).
Je n'ai en revanche jamais été trahis par short et long (mes 1eres lignes de code ASM / C étaient sur processeur intel en mode réel, d'où ma haine du type int qui m'a trahis une ou deux fois).
CF: stdint.h
"Le standard C spécifie une valeur que chaque type entier doit être capable de représenter "
de représenter quoi? La phrase se fini sur une référence... mais éplucher le standard, comment dire...
Par rapport aux énumérations, je souhaite indiquer qu'il me semble que C++11 (ou est-ce le C11?) a apporté des contrôles sur la façon dont une structure occupe l'espace mémoire, laissant aux développeur le choix de la densité mémoire (vu qu'un processeur 32bits manipule plus vite les doubles mots que les mots, comparé à un processeur 16 bits de même fréquence, si je me plante pas).
"ce qui explique pourquoi les systèmes win32 ne peuvent pas utiliser plus de 4 Go de mémoire."
C'est juste que la médiocrité du kernel windows n'est pas que une rumeur. Et d'ailleurs, même si je doute que les windows 32 bits pour les utilisateurs soient effectivement capable d'adresser 64Gio quand compilés en 32bits, je doute que les versions serveur n'en soient pas capables.
"Vous devez faire attention avec les types numériques dans le standard C, les int et short ont la même valeur limite à stocker (unsigned int et unsigned short ont tous deux 0xFFFF (i.e. 16 bits)). Je n'ai jamais eu de problème avec ça, mais un int pourrait être représenté par 16 bits."
D'un côté tu dis qu'un int pourrait être stocké sur 16 bits, et de l'autre tu dis qu'un int pourrait être représenté sur 16 bits???
Bon, a part ça, mes constatations personnelles, c'est que, si le programme est compilé avec le compilo borland pour générer un binaire 16 bits, int sera sur 16. Si pour 32, int sera sur 32 (la raison pour laquelle je m'en sers pas est d'ailleurs que j'ai longtemps programmé en mode réel, c'est à dire sur intel 16 bits). J'imagine que pour une bécane 64bits, ce sera 64...
Voili voilou mes impressions.
Sinon, bonne initiative. J'ai personnellement eu une passe ou je me suis intéressé de très près au reverse engineering (bon, ok, cracking), à l'assembleur et au BIOS, même si elle date. Je pense que ça m'aide énormément dans ma compréhension du fonctionnement d'un programme (dans le genre intéressant, il y a aussi les fameux ring, ou niveaux d'exécutions).
J'avais d'ailleurs beaucoup appris de tuto asm de dvp, et de 2 autres documents dispos sur la toile:
_ les secrets du BIOS PC/AT (je crois) qui traitait d'assembleur et des routines d'interruptions du BIOS
_ un ouvrage qui décrivait pas à pas comment écrire son kernel (mais je m'étais arrêté presque au début: ces histoires de mode réel/protégé et la complexité de la gestion de la mémoire m'ont fait fuir)
PS: Visual Studio n'est pas vraiment une référence en terme de standard. Je tiens à rappeler que microsoft ne supporte toujours pas stdint.h par exemple, donc il faudrait cesser de se fier à ce compilateur pour jauger le standard.
Et je ne dis pas ça pour troller... J'ai eu de mauvaises expériences à ce sujet, notamment avec 2005, et bien qu'ils se soient améliorés, il n'empêchent qu'ils ne respectent toujours pas certains trucs élémentaires.
Pour mettre les choses entre parenthèses, il me semble qu'un seul compilateur (et ce n'est pas GCC, je vois venir les trolls) implémente les normes de 99 entièrement, à cause d'une fonctionnalité qu'ils ont d'ailleurs chaudement recommandé aux autres de NE PAS faire ;)
En gros, en tous cas je l'ai compris comme ça.Citation:
Envoyé par Freem
Si le standard dit qu'un int doit pouvoir stocker 65535, rien n'empêche l'implémentation de pouvoir stocker 99999. Mais c'est implémentation spécifique.
Je veux bien, mais ?Citation:
Envoyé par Freem
Citation:
L'OS préféré des bidouilleurs est comme les autres, il a parfois un peu de mal à prendre en charge 4 Go de mémoire vive (ou plus). [...] Pour ceux qui ont suivi, en 32 bits classique (x86, évidemment), Linux limite la mémoire de la même façon que Windows (et Mac OS X sur un CPU sans le PAE) : on se retrouve avec 3,25 Go utilisables (environ et en fonction de la machine) sur les 4 Go car les périphériques nécessitent un espace mémoire dans la mémoire vive (pour l'adressage des périphériques) pour être utilisé
cf. http://stackoverflow.com/questions/5...f-int-long-etc et http://www.open-std.org/JTC1/SC22/WG...docs/n1256.pdf (p22)Citation:
Envoyé par Freem
- signed char: -127 to 127 (note, not -128 to 127; this accommodates 1's-complement platforms)
- unsigned char: 0 to 255
- "plain" char: -127 to 127 or 0 to 255 (depends on default char signedness)
- signed short: -32767 to 32767
- unsigned short: 0 to 65535
- signed int: -32767 to 32767
- unsigned int: 0 to 65535
- signed long: -2147483647 to 2147483647
- unsigned long: 0 to 4294967295
- signed long long: -9223372036854775807 to 9223372036854775807
- unsigned long long: 0 to 18446744073709551615
Un int doit pouvoir représenter 65535, soit 16 bits. Ni plus, ni moins. Or aujourd'hui il est communément admis qu'un int fera 32bits, les archis 32 bits étant la norme depuis un moment, et bientôt les 64 bits. Mais il peut n'être stocké que sur 16 bits.
Oui int est le piège typique. Et il faudrait favoriser au moins short et long.
Je vais sûrement dire une bêtise mais l'int n'est-il pas défini comme le type optimal pour effectuer des calcul en un seul cycle CPU?
int est defini comme etant la taille naturelle pour l'implementation. Le processeur mais aussi l'OS ont leur mot a dire, et c'est l'OS qui predomine.Citation:
Envoyé par Neckara
En passant, si on se limite aux desktops, stations de travails et serveurs (en excluant donc l'embarque, ou il y a plus de variete, et les machines historiques, dont je doute qu'elles soient programmees en C ou en C++) le seul type de taille variable est long qui est sur 32 bits (pour les implementations ILP32, autrement dit 32 bits, et LLP64, Windows) ou sur 64 bits (pour les implementations LP64, Unix).
Désolé, c'est vrai que j'aurai du citer:Citation:
Envoyé par Bousk
Cela signifie qu'une architecture 32 bits, si elle supporte PAE, peut adresser jusqu'à 64Go de RAM, et pas 4 comme il est communément admis.Citation:
Quand votre machine est compatible PAE (la majorité des processeurs Intel depuis le Pentium Pro, en dehors des Pentium-M et Core Duo), il est possible d'utiliser 4 Go (ou plus, 64 Go au maximum) sur une machine 32 bits.
A titre d'info, wikipedia m'indique que le pentium pro date de 1995, bien avant l'arrivée du 64bits.
Je voulais en fait signifier que ta phrase est étrange:Citation:
"les int et short ont la même valeur limite à stocker ([...](i.e. 16 bits)).[...]un int pourrait être représenté par 16 bits"
Tu te répètes, non?
Pour tout le reste de ce que tu cites et réponds, j'ai un test pour toi, vu que tu sembles penser que les spécificités d'implémentations sont rares.
Il te faudra 2 compilateurs, plutôt répandus: Visual C++ 2008 et MinGW32.
Compiles et exécutes le code suivant sur chacun d'eux.
J'insiste, j'ai essayé uniquement avec C++, le C agira peut-être de la même façon dans les deux cas (ces langages ne sont pas les mêmes après tout)
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Ce bout de code n'a rien à voir avec la taille des types, je te l'accorde. Son seul rôle est de te montrer que les spécifités d'implémentation doivent être prises au sérieux, car les résultats obtenus avec ces deux compilateurs diffèrent, et sont pourtant tous deux standard!
Quand j'ai utilisé cette astuce pour un code, j'avais "communément admis" que l'ordre de passage des données à une fonction était fixe, normé, standard, ce qui est entièrement faux: cela dépend du contexte (en gros, seul le cas ou le retour d'une fonction est attendu est fixe, si c'est une expression, le compilateur est libre de faire les "optimisations" qu'il veut. J'ai perdu 2 jours à comprendre pourquoi ce bout de code ne marchait pas sous windows mais marchait sur ma machine perso. Bizarrement, j'ai accusé sans savoir VS de merder :aie:)
Les spécificités d'implémentation, c'est standard en C et en C++ (au moins pour le 2nd qui encourage les optimisations spécifiques aux distributeurs de compilos) !Citation:
Envoyé par Bousk
C'est justement ce flou volontaire qui fait que ces langages sont portables.
La portabilité dont je parle ici est celle de la machine, de l'OS, ET du compilateur.
Si tout était fixé, un compilateur ou un autre n'auraient aucune importance.
"Ni plus, ni moins" sur le 1er lien, on peut lire, dans le 1er commentaire du 1er lien (3x plus approuvé que les autres): "The C++ standard does not specify the size of integral types in bytes, but it specifies minimum ranges they must be able to hold. "Citation:
Un int doit pouvoir représenter 65535, soit 16 bits. Ni plus, ni moins. Or aujourd'hui il est communément admis qu'un int fera 32bits, les archis 32 bits étant la norme depuis un moment, et bientôt les 64 bits. Mais il peut n'être stocké que sur 16 bits.
Oui int est le piège typique. Et il faudrait favoriser au moins short et long.
qui signifie que le standard indique le nombre de valeurs minimum qui doit être supporté, mais pas le maximum. Aussi, un int de 18 bits serait tout à fait standard, même si spécifique à son implémentation.
Les langages C et C++ sont conçus pour leur portabilité avant même leur performance, et imposer des tailles précises pour un type empêcherait les deux.
Quant au "communément admis"... cf mon exemple plus haut. En toute honnêteté, quel résultat pensais-tu avoir avant de faire le test? Le même sur chaque compilo? Dans mon esprit, il était communément admis que "cdecl" était valide en C++ quelle que soit la situation...
"les archis 32 bits étant la norme depuis un moment, et bientôt les 64 bits"
Ce n'est pas une norme, c'est juste répandu.
Si un industriel avait un besoin d'une puce plus petite et que pour cela il doive avoir un système fonctionnant avec 8 bits (je dis n'importe quoi hein) ou bien le contraire, 128, des programmes C et C++ bien écrits devraient être capables de s'exécuter sans modification des sources (mais en recompilant) sur ces machines (en admettant que les capacités matérielles soient suffisantes pour charger les programmes en mémoire, bien entendu).
Il faut se méfier de ce que l'on pense être la norme, et se rappeler que C et C++ sont deux langages différents (bien que mon exemple adapté au C, semble causer le même problème compilé en C qu'en C++).
Aucune idée. En revanche, si tu veux de l'optimisation, je te conseille de regarder int_fast8_t int_fast16_t int_fast32_t int_fast64_t uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_tCitation:
Envoyé par Neckara
cf: http://pwet.fr/man/linux/conventions/posix/stdint_h
(contrairement au fait que ce soit un man, qui parle de POSIX, il s'agit du standard C99: http://fr.wikipedia.org/wiki/Bibliot...es_ANSI_et_ISO
[edit]
désolé pour le long post, et désolé pour le 1er pas toujours assez clair, je l'admets.
Non, tu comprends de travers ce que j'ai voulu dire.Citation:
Envoyé par Freem
Au jour d'aujourd'hui où le pc standard est un 32bits, il est plus ou moins admis qu'un int sera 32bits, le mot naturel du proc.
Mais la norme ne spécifie rien de plus pour le int que de pouvoir stocker 65535. Et donc on peut avoir un int représenté de 16bits (qui suffit à stocker cette valeur max).
Peu de personnes le savent au premier abord, mais effectivement l'ordre de passage des paramètres, lorsqu'ils sont retour de fonction, n'est pas standard.Citation:
Envoyé par Freem
Je m'en suis aperçu en lisant une documentation sur le développement PSP lors de mon stage, et sur le coup ça m'avait surpris.
De même que le mot-clé volatile existe pour guider le compilateur dans certaines de ses optimisations.
Ni plus ni moins s'applique à ce que dit la norme. Le passage en gras. Pas au range de valeurs possibles. Désolé du flou.Citation:
Envoyé par Freem
La norme dit, ni plus ni moins, qu'un int doit pouvoir stocker 65535. Elle n'interdit pas de stocker plus grand, mais il ne doit pas avoir une limite plus basse.
De même qu'un int de 18bits n'a rien de standard. La norme ne l'interdit pas, mais le standard du jour ça reste le 32 bits aux yeux de la grande majorité.
Quand tu travailles avec ce genre de bestioles, tu es au courant d'une telle spécificité. Mais je le répète : ça reste une spécificité. Fusse-t-elle non interdite par la norme.
Quand c'est aussi répandu, je parle de normalité, désolé.Citation:
Envoyé par Freem
Quand je bosserai sur un système où un int devra faire 8 bits, je m'y adapterai. Mais ça ne sera pas du tout normal, on s'y pliera. Quand on parle de spécificités de ce type on est quand même bien loin de la normale. Et on sait y faire face normalement.
D'accord, je comprends mieux ce que tu voulais dire du coup.
Je suis curieux de voir la raison pour laquelle ils t'ont expliquer que l'ordre des paramètres change? Parce que dans mon cas, c'était une astuce pour appeler une fonction dont le programme ne connaît pas lui-même le nombre d'arguments... le genre de bestiole qu'on ne voit pas tous les jours :aie:
Ce n'était pas l'ordre des paramètres, mais l'ordre de résolution de ceux-ci.Citation:
Envoyé par Freem
De mémoire, en gros, avec un code comme ça :
là où en général doSomething sera exécuté en premier, puis getFrom, puis MyFunction avec les 2 retours, sur PSP ça risquait de faire d'abord getFrom, puis doSomething, puis MyFunction, les méthodes étant résolues de droite à gauche.Code:MyFunction(doSomething(1), getFrom(a));
Problèmes évidents en vue si les méthodes utilisent/modifient un même paramètre, ou font de la tambouille interne sur une même classe. :aie:
C'est étrange, parce qu'il me semble justement que lorsque l'on appelle des fonctions/méthodes pour utiliser leur résultat directement dans une fonction, alors les fonctions doivent être résolues dans un ordre précis (d'où ma solution qui avait été de faire une fonction inline, justement)...
Va falloir que je refasse quelque recherches, j'aimerai pas retomber dans ce piège... (et d'ailleurs, l'ordre "logique" est de résoudre le dernier paramètre en premier. Passer le 1er en 1er, c'est ce que fait le pascal, si je ne m'abuse)
Il y a 3 choses:Citation:
Envoyé par Freem
- la taille des adresses dans un processus
- la taille des adresses physiquement disponible
- la taille des adresses physique prevue par l'architecture.
Quand on dit qu'une machine 32 bits adresse 4GB au maximum, on parle de la premiere. PAE permet d'etendre la troisieme jusqu'a 64GB, les processeurs 32 bits ont en pratique quelque chose entre les deux. (Bon, vu que ca fait un bon moment que les processeurs sont 64 bits, la taille maximales adresses physiques tournent autour entre 40 et 50 bits et plus 36; je ne sais pas a quel point il y a une limite architecturale inferieure a 64 bits, c'est un aspect que j'ai jamais regarde).
Le passage d'une taille physique limitee a moins que ce qui est logiquement possible dans un processus a quelque chose de plus s'est vu de nombreuses fois. Parfois meme par hard exterieur (voir p.e. http://en.wikipedia.org/wiki/Expanded_memory pour rester sur la meme plateforme, mais ca s'est vu ailleurs aussi).Citation:
A titre d'info, wikipedia m'indique que le pentium pro date de 1995, bien avant l'arrivée du 64bits.
Ta ligne 12 est un cas de comportement non specifie bien connu (autrement dit l'implementation a un nombre limite de possibilites et elle n'est pas obligee d'indiquer comment elle fait).Citation:
Quant au "communément admis"... cf mon exemple plus haut. En toute honnêteté, quel résultat pensais-tu avoir avant de faire le test?
Ta ligne 14 est un cas de comportement indefini bien connu aussi (autrement dit, l'implementation peut faire ce qu'elle veut a partir du moment ou elle est sure que le code est execute, j'ai meme vu des comportement "non causaux" -- elle supposait qu'un comportement indefini -- pas celui-la -- n'avait pas lieu, ce qui limitait les valeurs possibles et avait donc determine qu'un test anterieur etait toujours faux et l'avait vire ainsi que le code correspondant).
Norme en francais a plusieurs sens dont un est justement le comportement le plus frequent.Citation:
Ce n'est pas une norme, c'est juste répandu.
Note que quelque chose d'impose par une norme (au sens de document sortant d'un organisme de normalisation) peut etre en pratique moins reliable que quelque chose de moins formel.
Certains s'amusent a faire des nuances entre "norme" et "standard", ca peut aider quand on est au courant, mais de telles nuances sont loins d'etre universelles.
L'ordre d’évaluation des arguments est totalement au choix du compilateur. Si on a des effets secondaires qui font que cet ordre importe, c’est à nous de décomposer l'expression et de passer par des variables intermédiaires.Citation:
Envoyé par Freem
Mais ce n'est pas toujours possible de séparer le calcul des arguments.Citation:
Envoyé par JolyLoic
En l'occurrence, j'avais eu recours à cette "technique" (très sale, j'en conviens) parce que je devais appeler une fonction dont le compilateur n'a aucune idée du nombre d'arguments. Contrairement au développeur...
Une sorte de génération de code en live quoi.
Pour ceux qui connaissent, il s'agit "d'injecter" du code natif dans une application utilisant powerbuilder. Vue la tronche de l'API (qui prétends être écrite en C++ mais en fait il s'agit de C with classes version plug-in, c'est à dire avec des structures au lieu des classes, entres autres) j'avais eu à en encapsuler une bonne partie. Et comme les fonctions/méthodes de PB n'ont pas de nombre d'arguments déterminé à l'avance, et que l'on me demandait un système automatisé au maximum... j'ai fait ce que j'ai pu (et pas le droit aux dépendances externes, ni au tr1 vu que ça doit compiler avec VS2008 naturellement).
Citation:
Envoyé par Freem
me semble toujours possible. Pas folichon, mais quand on a des evaluations de parametres qui ont des effets de bords, il faut pas venir se plaindre.Code:
2
3
4