Discussion :

[ternel]

Ah oui, je vois ton soucis.
Il y a un gros piège: 'a' n'est pas une constante de type char, mais de type int.
Si si.

C'est une disposition qui a été prise pour permettre l'utilisation des "constantes de multicaractères" comme int toto = 'to';.
La valeur de telles constantes est définies par l'implémentation, et en règle général, leur usage est une erreur.

Personnellement, je n'en connais aucun usage dans du code classique. Peut-être dans un embarqué?

Un type possède une unique représentation, que ce soit pour une variable ou une valeur temporaire (de ce type).
Essaye donc

Code :

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

    (void)fprintf( stdout, "taille de 'a': base: %lu\tchar: %lu\tlong long: %lu\n", sizeof('a'),sizeof( (char)'a' ), sizeof( (long long)'a' ) );

Pour le C (et le C++), la norme est le langage, puisque c'est le traité international le définissant.
Tout compilateur déviant de la norme n'est pas conforme au C.

C'est une différence majeure avec le Java, par exemple, qui est défini par son implémentation de référence.

[sambia39]

Ok, je suis d'accord avec vous sur les multiples cependant moi je parle du comportement de sizeof vis-à-vis du modèle que l'on a adopté pas de sizeof char == 1:
si 'a' n'est pas une constante de type char, mais de type int. c'est parce que cette taille correspond à un mot machine donc directement à l'architecture et donc au modèle que l'on a adopté ce n'est pas à cause du type en lui-même c'est de ça que je parle pas de multiple ou de char :

The C programming language lacks a mechanism for adding new fundamental datatypes. Providing 64-bit addressing and scalar arithmetic capabilities to the C application developer involves changing the bindings or mappings of the existing datatypes or adding new datatypes to the language.

There are three basic models that can be chosen, LP64, ILP64 and LLP64 as shown in the following table. The notation describes the width assigned to the basic data types. LP64 (also known as 4/8/8) denotes long and pointer as 64 bit types, ILP64 (also known as 8/8/8) means int, long and pointer are 64 bit types and LLP64 (also known as 4/4/8) adds a new type (long long) and pointer as 64 bit types. Most of today's 32 bit systems are ILP32 (that is, int, long and pointers are all 32-bits wide). The majority of C Language programs written today for Microsoft Windows

Donc pour moi sizeof de type de données, l’opérateur sizeof renvoie la taille du type de données et pour une expression, sizeof renvoie la taille du type de variable ou de l’expression(renvoie donc la taille mémoire nécessaire de stockage, en octet, pour stocker un objet du type de l'opérande en ce basant sur le model adopté)


Aprés je peut me trompé car moi je comprend sa comme ça.
je pense que j'en ai énervé plus d'un .... dsl

[ternel]

Ces modèles d'architectures sont les trois modèles classiques, mais ne sont ni normatifs, ni les seuls à exister.
Il me semble qu'il existe des machins bizarres du type tout est sur 64 bits (de char à long long), ce qui a pour conséquence que tous les sizeof de types fondamentaux valent 1.

D'où tires-tu cette citation?

si 'a' n'est pas une constante de type char, mais de type int. c'est parce que cette taille correspond à un mot machine donc directement à l'architecture et donc au modèle que l'on a adopté ce n'est pas à cause du type en lui-même c'est de ça que je parle pas de multiple ou de char :

La constante litérale de caractère 'a' est de type int, parce que le langage l'a décidé.

Le type int est de la taille que décide l'implémentation, mais généralement c'est le "mot machine". Encore que la définition de cette chose-ci reste floue.
Dans mon souvenir, et c'est avec moult pincettes que je le dis, il s'agit de la largeur du bus de données entre la mémoire et le processeur.

Par exemple parmi les sytèmes ayant un adressage sur 64bits, les LLP64 (WIN64 API) utilisent un int et un long de 32 bits, les LP64 (Linux et Mac OS X) utilisent un int de 32, et seuls les très rares ILP64 (certains vieux UNIX comme l'unicos sur cray) ont un int de 64 bits.
Quelle est la taille du mot machine dans ces différents cas? Je ne saurais dire exactement

Les choix de l'implémentation ne sont pas très significatifs devant ceux du langage, et ne devrait pas entrer en considération dans du code portable, qui est un objectif usuel.

PS: et il n'y a pas d'énervement. Simplement de la précision dans le discours.

[sambia39]

Alors d'où je tire cette phrase de là en partie:

Ah oui, je vois ton soucis.
Il y a un gros piège: 'a' n'est pas une constante de type char, mais de type int.
Si si.

C'est une disposition qui a été prise pour permettre l'utilisation des "constantes de multicaractères" comme int toto = 'to';.
La valeur de telles constantes est définies par l'implémentation, et en règle général, leur usage est une erreur.
.......

Comme tu viens de le dire la taille d'un int n'est pas défini et généralement c'est un mot machine chose que j'ai déjà dite et encore une fois je contredis pas ce que vous avez dit je dis juste que la valeur renvoyer de sizeof n'est pas forcément du type de la norme mais du modèle adopté et c'est un peu ce que médinoc a parlé." le modèle adopté" et sur ce modèle alors on va définir les types et le lien que j'ai mis est là pour apporter plus de précision.

au final je me suis j'ai été mal compris

[ternel]

Alors d'où je tire cette phrase de là en partie:


Comme tu viens de le dire la taille d'un int n'est pas défini et généralement c'est un mot machine chose que j'ai déjà dite et encore une fois je contredis pas ce que vous avez dit je dis juste que la valeur renvoyer de sizeof n'est pas forcément du type de la norme mais du modèle adopté et c'est un peu ce que médinoc a parlé." le modèle adopté" et sur ce modèle alors on va définir les types et le lien que j'ai mis est là pour apporter plus de précision.

au final je me suis j'ai été mal compris

Non, la phrase en gras est fausse. (note d'un point de vue langue, tu voulais dire "la valeur renvoyée par sizeof n'est pas forcément celle du type de la norme mais celle du modèle de données adopté par l'implémentation")

J'espère pour toi que la valeur renvoyée par sizeof est celle que la norme demande, à savoir le nombre de byte de la représentation en mémoire du type (ou du type de l'expression) donné en opérande.
La norme spécifie que la taille exacte des types est définie par l'implémentation, c'est-à-dire, la combinaison du compilateur, de ses options, et de l'architecture cible.
Elle spécifie par contre une plage de valeur que doit pouvoir représenter chaque type, ce qui signifie un nombre de valeurs distinctes requises. Ces plages sont choisies pour être représentables par un nombre entier d'octets. Rien n'interdit les types fondamentaux de pouvoir représenter plus de valeurs.

Le modèle adopté est un détail de l'implémentation.
Ainsi, sizeof int n'est pas défini par la norme comme une valeur précise (ce n'est ni 1 ni 2 ni 4), mais comme "le nombre de bytes requis par la représentation en mémoire des variables de type int, à savoir, des entiers dans [-2 147 483 647, 2 147 483 647]".
Le nombre de bits correspondant est obtenu par CHAR_BIT * sizeof int.
Si jamais tu avais un processeur avec 10 bits par byte, il y a de grandes chances que l'int fasse 40 bits.

[sambia39]

D'accord , là-dessus je comprends mieux la choses
Merci

[koala01]

Salut,

Et pourtant, sizeof renvoie bien un multiple de sizeof char.
La norme exige que sizeof char == 1. Et sizeof retourne un entier.

Pour le reste on est globalement d'accord.

Je précisais simplement que la fonction parle d'octets, mais ce n'est pas exact.
Si sur une architecture, le char fait 2 octets (ce qui est parfaitement légitime), sizeof char retourne quand même 1, et la fonction affichera "Un char fait 1 octets."

En fait, tout le problème vient de nos tentatives désespérées d'utiliser des termes français à la place des termes anglais, et d'habitudes prises il y a fort longtemps pour être encore valides.

Car le terme octet fait explicitement référence au préfixe octa/octo, qui signifie 8 en grec et qui part du principe qu'un byte (la plus petite unité adressable en mémoire) est forcément composée de ... 8 bits.

C'était vrai à l'époque d'où vient cette habitude, ca l'est encore plus ou moins à l'heure actuelle, mais ça pourrait très bien ne pas le rester indéfiniment : il suffirait qu'un fondeur ou qu'un éditeur de système d'exploitation décide, par exemple, de tout faire ne UTF16 ou en UTF32 pour que la taille d'un caractère (et donc la taille du plus petit élément adressable) en mémoire passe à ... 16 ou à 32 bits.

Dans cette hypothèse, CHAR_BITS ne vaudrait donc plus 8, comme nous pouvons nous rendre compte qu'il le fait quasiment partout pour l'instant, mais ... 16 ou 32 selon le choix fait par le fondeur ou l'éditeur de système d'exploitation; et sizeof(char) serait toujours égal à 1. Quitte, d'ailleurs, à ce que sizeof(short) et (pourquoi pas, après tout ) sizeof(int) soient aussi égaux à 1, car la norme dit bien que la taille d'un short est plus grande ou égale à celle d'un char et que la taille d'un int est plus grande ou égale à celle d'un short .

C'est la raison pour laquelle je préfèrerais largement parler de multiplet plutôt que de parler d'octet pour "franciser" le terme de byte, car cela éviterait bien des assertions "douteuses" quant au nombre de bits nécessaire à la représentation d'un char en mémoire.

Malheureusement, les habitudes, c'est comme la mauvaise herbe : c'est pour ainsi dire increvable

[Pyramidev]

Personnellement, en français, je préfère que le terme byte reste plus populaire que multiplet.

Octet, bit et byte sont généralement abrégés, respectivement, en o, b et B.
Par exemple, 4 Go/s = 4 gigaoctets par seconde.
Je n'aimerais pas qu'on abrège multiplet en m, car c'est déjà le symbole du mètre.
D'un autre côté, il serait dommage qu'une unité n'ait pas d'abréviation.

[Matt_Houston]

il suffirait qu'un fondeur ou qu'un éditeur de système d'exploitation décide, par exemple, de tout faire ne UTF16 ou en UTF32 pour que la taille d'un caractère (et donc la taille du plus petit élément adressable) en mémoire passe à ... 16 ou à 32 bits.

Le terme char et l'unité adressable n'ont de nos jours que peu de choses à voir avec la représentation d'un caractère en tant que graphème. Et l'UTF-16 est d'ailleurs un codage à taille variable (une autre raison de son infériorité : c'est le pire des deux mondes entre UTF-8 et UTF-32) : un caractère peut être codé sur un ou deux mots.

Les causes d'un tel changement s'il devait se produire seraient plutôt à chercher au sein des évolutions technologiques matérielles.

Octet, bit et byte sont généralement abrégés, respectivement, en o, b et B.
Par exemple, 4 Go/s = 4 gigaoctets par seconde.

Il existe des préfixes binaires dédiés pour les ordres de grandeurs de données qui sont plus en phase avec les quantités que nous manipulons quotidiennement en tant que développeurs.

[Pyramidev]

Il existe des préfixes binaires dédiés pour les ordres de grandeurs de données qui sont plus en phase avec les quantités que nous manipulons quotidiennement en tant que développeurs.

Je connais les préfixes binaires.

Mais, en télécommunication, quand on exprime des grandeurs de débit binaire, par convention, les préfixes kilo-, méga-, giga-, etc. représentent bien des puissances de 10. Ainsi, quand on écrit 1 Go/s, il s'agit bien d'un milliard d'octets par seconde et non pas de 2 puissance 30 octets par seconde.

C'est pour la mémoire des disques durs qu'il existe une ambigüité dans le langage courant avec les préfixes kilo-, méga-, giga-, etc. qui désignent des puissances de 10 dans la norme, mais des puissances de 2 dans les habitudes.

EDIT : Je nuance ce que je viens d'écrire.
Dans le lien wiki, je lis : « Quand le débit est exprimé en octets par seconde, on utilise parfois implicitement des puissances de 1024. Donc 1 ko/s peut représenter 1 024 o/s au lieu de 1 000 o/s. »
Pourtant, à l'école, on m'avait appris que, en télécommunication, pour le débit binaire, kilo-, méga-, giga-, etc. désignaient toujours des puissances de 10.

[koala01]

Le terme char et l'unité adressable n'ont de nos jours que peu de choses à voir avec la représentation d'un caractère en tant que graphème. Et l'UTF-16 est d'ailleurs un codage à taille variable (une autre raison de son infériorité : c'est le pire des deux mondes entre UTF-8 et UTF-32) : un caractère peut être codé sur un ou deux mots.

Les causes d'un tel changement s'il devait se produire seraient plutôt à chercher au sein des évolutions technologiques matérielles.

Quelle que soit l'origine du changement et quel qu'il puisse être, il n'en reste pas moins que, d'une manière ou d'un autre, on a l'équivalence entre la notion du type char et la notion de byte et que cette équivalence peut se perdre lorsque l'on se met à parler d'octet.

Il suffit en effet que, pour quelle que soit la raison, un byte ne fasse plus huit bits de long, et, bien que l'équivalence byte <==> char soit maintenue, l'équivalence char <==>octet ne le sera pas parce que, justement, octet == 8 bits, de par sa racine octa

@Pyramidev c'est la raison pour laquelle j'estime que certains termes technique ne devraient pas être francisés.

Autant je n'ai rien contre le fait de parler d'accesseur ou de mutateur au lieu de parler de getter et de setter (je le fais moi même plus qu'à mon tour), autant je peux concevoir l'intérêt qu'il y a à ne pas laisser sa langue être envahie par des termes étrangers (malgré le fait que ca a toujours été et que ce sera toujours), autant je trouve que, dans certaines circonstances, la traduction "à tout prix" de certains termes est à tout le moins mal venue.

Et c'est surtout vrai pour toutes ces traductions "approximatives" qui se basent sur des assertions qui étaient sans doute vraies au moment où les traductions sont "entrées dans les moeurs" mais qui peuvent s'avérer fausses dans un avenir "plus ou moins proche".

Quant au fait que m est le symbole du metre et que m pour "multiplet" pourrait "introduire les gens en erreurs", il y a de nombreux cas dans lesquels un symbole donné a une signification différente selon le domaine envisagé. Cela me semble être la moins bonne des raisons à invoquer pour décider de résister au changement