Réunion des comités de normalisation de C et C++

En réalité, long et int ne sont pas identiques.

Quelle est la différence alors ?

sizeof(int) <= sizeof(long). C'est tout ce qui les différencie officiellement. Après, cela dépend de la plateforme.

Merci infiniment pour ces retours.

Concernant les symboles manquants, c'est un faux argument, il y a déjà des opérateurs qui sont en fait des mots comme sizeof et _Alignof. Du coup, _Rol et _Ror seraient parfaitement possible. Par contre, j'ignorais que certain processeur ne supportait pas la rotation de bits, il me semblait pourtant que c'était une opération assez courante et plutôt basique. À défaut, déjà deux opérateurs pour décaler un entier vers la droite en conservant le signe ou non.

Je ne suis pas certain d'être en mesure de rédiger un article en ce sens au comité de normalisation.
Maintenant, juste pour savoir : n'importe qui peut envoyer une proposition ou bien il y a des conditions ?

Ah… Est-ce qu'il est possible de savoir en quoi ce système est utile/avantageux par rapport à une bibliothèque complète comme gettext ou ICU qui propose bien plus de fonctionnalités et de garanties ?

• Ajouter un opérateur bitsof qui fournirait le nombre de bits de valeur composant un type.
• Ajouter des opérateurs maxof et minof qui donnerait respectivement le maximum et le minimum d'un type.

Il y a des travaux en cours pour ajouter des macros qui semblent aller dans ce sens. Voir le chapitre 13 "Integer width macros" du papier N1711: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1711.pdf

Intéressant. Je note juste que dans la proposition, la grandeur des types signés et non signés est la même alors qu'elle devrait être inférieur d'une unité suivant la norme.

Cela y ressemble, en effet, mais ce n'est pas de l'héritage à proprement parler. L'objectif est juste de simplifier certaines écritures et d'éviter des recopies.

Concernant le type word proposé ci-dessus, j'ai du mal à savoir si c'est une bonne idée, j'ai dû mal à voir quand il serait utile. Par contre le nom word est lui très mal choisi. En programmation windows on a déjà le type WORD qui est un alias pour unsigned short.

Je serais tenté de dire que c'est Windows qui a fait un mauvais choix, mais bon.

Tu veux parler du fait que l'API Windows utilise ce type ?

sizeof(int) <= sizeof(long). C'est tout ce qui les différencie officiellement. Après, cela dépend de la plateforme.

C'est ça qui est énervant en fait. C'est défini n'importe comment, il n'y a aucune logique et rien n'est garanti nulle part. Parce que si je suis bien, le standard dit juste que 1 = sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long). Donc sizeof(long long) peut être = 1, et on peut avoir n'importe quoi entre deux… la seule chose de sûre à 100% c'est sizeof(char)=1.

ON ne va pas réinventer les types, mais c'est dommage que les relations ne soient pas des égalités strictes. Ca aurait été beaucoup plus clair, ça aurait fixé quasiment d'office sizeof(short)=2, sizeof(long)=4 et sizeof(long long)=8; en sortant éventuellement le type int du lot pour qu'il corresponde toujours à la taille d'entier optimale (d'ailleurs, c'est longtemps la définition qu'on m'a donné pour le type int: un entier dont on ne se soucie pas en détail des bornes mais qui est toujours optimal pour le processeur peu importe la plateforme; et donc du même coup, adieu int_fast_t et autres).

De même, si je pige bien, on a aussi sizeof(float) <= sizeof(double) <= sizeof(long double). Donc parfois on peut avoir sizeof(double) == 4 et sizeof(long double) == 4.

Je serais tenté de dire que c'est Windows qui a fait un mauvais choix, mais bon.

JE pense que si on a hérité de ce nom, c'est surtout pour des raisons historiques. Dans la même logique, on a DWORD et QWORD pour unsigned long et unsigned long long. Ca se comprend: word = groupe de 2 bytes, et double word = groupe de 4 bytes, et ça correspond à l'asm intel.

Tu veux parler du fait que l'API Windows utilise ce type ?

Ben oui, abondamment même, dans les logiciels modernes et biens conçus. L'unicode (enfin, UTF-16 modifié à la sauce Microsoft) est censé être la norme depuis Windows XP au moins (peut-être même 2000). En réalité on n'utilise pas wchar_t mais WCHAR… parce que l'API windows est le spécialiste pour ajouter plein de typedef; mais c'est pareil.

Parce que si je suis bien, le standard dit juste que 1 = sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long). Donc sizeof(long long) peut être = 1, et on peut avoir n'importe quoi entre deux… la seule chose de sûre à 100% c'est sizeof(char)=1.

C'est pire que ça, la taille d'un byte n'est pas définit, mais le nombre de bit minimum l'est:

• 8 pour char (C++14)
• 16 pour short
• 16 pour int
• 32 pour long
• 64 pour long long

Donc si sizeof(long long) = 1, alors tous les types font au moins 64 bits.

c'est longtemps la définition qu'on m'a donné pour le type int: un entier dont on ne se soucie pas en détail des bornes mais qui est toujours optimal pour le processeur peu importe la plateforme; et donc du même coup, adieu int_fast_t et autres.

Les types optimaux diffèrent selon le nombre de bits minimal voulu. Sur ma machine, int_fast8_t = signed char, les autres = long. Avec sizeof(int) = 4 et sizeof(long) = 8.

Seul le type char est garanti efficace. C'est d'ailleurs pour cela qu'au niveau type char != signed char != unsigned char.

De même, si je pige bien, on a aussi sizeof(float) <= sizeof(double) <= sizeof(long double). Donc parfois on peut avoir sizeof(double) == 4 et sizeof(long double) == 4.

Ouaip. En plus, les valeurs et la norme sont définies par l'implémentation. Techniquement, on pourrait avoir un long double de 8 bits avec une mantisse de 0…

C'est pire que ça, la taille d'un byte n'est pas définit, mais le nombre de bit minimum l'est:

• 8 pour char (C++14)
• 16 pour short
• 16 pour int
• 32 pour long
• 64 pour long long

Donc si sizeof(long long) = 1, alors tous les types font au moins 64 bits.

Ah oui… c'est encore pire que ce que je pensais avoir compris. Mais du coup je ne comprends pas ta conclusion: si long long est garanti au moins 64 bits, alors on a nécessairement sizeof(long long)>=8, c'est impossible que sizeof(long long)=1. Ou alors il existe des processeurs ultra-bizarres où un byte ne fait pas 8 bits.

Seul le type char est garanti efficace. C'est d'ailleurs pour cela qu'au niveau type char != signed char != unsigned char.

Tu veux dire que char peut, selon la plateforme, équivaloir à signed char ou bien unsigned char ? J'ignorais ça… pour moi char a toujours été signé et le mot-clé signed m'a toujours paru être une précision inutile car implicite par défaut, mème à l'époque où je découvrais le C/C++ en 1998 sous DOS. Par contre le type int, je l'ai bien vu passer de 16 à 32 bits, lui.

Bizarre, façon de dire. Vieux surtout. https://fr.wikipedia.org/wiki/Byte .

Cela se base effectivement sur l'Assembleur des processeur x86, mais pour moi cela n'a pas de sens. En toute logique, le terme « mot » désigne soit un byte sur un processeur adressé par mots (autrement dit, sur un processeur qui ne sait pas gérer des caractères¹) soit la grandeur des registres entiers sur un processeur adressé par caractères.

La définition de type était bonne dans le cas du processeur 8086 d'Intel puisque les registres entiers étaient effectivement limités à 16 bits, mais n'est pas adaptée aujourd'hui.

Du coup, elle ne se repose pas tellement sur les fonctions standard C, si ?

C'est exactement ça, certains processeurs utilisent des bytes de 32 bits par exemple. En fait, ce sont des processeurs qui fonctionnent par mots et non par caractères, comme il en existait auparavant qui adressaient uniquement des mots de 36 bits (d'où l'inexistence de type dans le langage B).

Le plus souvent, le type char est un type signé, mais ce n'est effectivement pas fixé par la norme.

Heu… Je ne vois pas très bien comment cela serait possible étant donné qu'un long double doit au minimum pouvoir stocker des valeurs comprisent entre $1^{-37}$ et $1^{+37}$.

Le C standardise la norme pour les nombres à virgule. Rien vu de tel en C++.

Du coup, elle ne se repose pas tellement sur les fonctions standard C, si ?

JE n'ai aucune idée si les variantes unicode des fonctions standard sont effectivement standard ou si c'est des spécialités Microsoft. Ces fonctions sont incluses dans MinGW donc ça ne doit pas être si spécial que ça. Les linuxiens et/Ou les maqueux pourront confirmer ou infirmer. On a d'office toute une série d'équivalences comme celles-ci :

• strlen, strcat, strdup => wcslen, wcscat, wcsdup
• strcmp, strchr, strrchr => wcscmp, wcschr, wcsrchr
• printf, snprintf => wsprintf, snwprintf
• scanf, sscanf => wscanf, swscanf
• atoi, itoa, ltoa, strtol => wtoi, itow, lto, wcstol
• etc....

Après, effectivement, si on veut, on peut ne pas utiliser du tout la bibliothèque C standard et prendre directement les fonctions de l'API windows, p.ex. CreateFile/ReadFile/WriteFile/CloseFile à la place de fopen/fread/fwrite/fclose. Mème pour printf on en a une, sauf erreur FormatMessage ou FormatString. Mais je suppose que sous linux on peut aussi aller directement piocher dans la lib du kernel si on veut.

La libc permet juste de faire des programmes basiques qui soient portables… et encore, il y a des blagues par exemple avec les formats acceptés par printf qui ne sont pas pareils (j'ai des doutes sur des formats comme %ls, %lld, ou %#04X, ou le comportement de %f/%g/%e).

Tiens tant qu'on y est sur printf, est-ce qu'il existe un vrai équivalent à sprintf/snprintf en C++ ? Parce que encore maintenant j'utilise un cheat pas très glorieux :

1
2
3
4
5
6
7
8

string snsprintf (int max, const string& fmt, ...) {
string out(max+1, '\0');
va_list ap;
va_start(ap,fmt);
((size_t*)(out.data()))[-3] = vsnprintf((char*)out.data(), max, fmt.c_str(), ap);
va_end(ap);
return out;
}

Tu as std::to_string et la concaténation de string ? Ou encore std::ostringstream. Après, tu peux te coder un print avec des templates variadiques.

C'est là qu'est l'astuce.

Les fonctions que tu décris sont bel et bien standards depuis la norme C99 (en fait, déjà une poignée depuis la norme C89). Toutefois, ce que je reproche à ces fonctions, c'est le manque de garanties qu'elles offrent. En effet, ces fonctions sont tributaires de l'encodage utilisé par le système. Dès lors, si cela est très pratique dans le cas de la lecture de fichier produit par le système ou pour la gestion des entrées et sorties du terminal (et encore, cela ne fonctionne pas sous Windows sans faire appel à des fonctions système), c'est la misère quand tu souhaites utiliser un encodage spécifique. C'est même pire dans le cas des caractères larges littéraux et des chaînes de caractères larges littérales : ils sont convertis suivant un encodage déterminé par le compilateur… Pour la distribution d'exécutables, c'est juste la catastrophe (encodé en Latin-1 lors de la compilation et transmis sur un système qui utilise l'UTF-8 ou le Windows-1252).

Je comprends bien l'idée derrière ces fonctions, mais cela ne me semble vraiment pas une réussite en définitive. Après, j'ai peut-être loupé quelque chose dans l'histoire.

Les formats que tu décris sont standards depuis la norme C89, sauf ls qui ne l'est que depuis le C99.

C'est même pire dans le cas des caractères larges littéraux et des chaînes de caractères larges littérales : ils sont convertis suivant un encodage déterminé par le compilateur…

Ah oui, j'ai souvent ce problème. Quand je veux mettre un caractère accentué dans un littéral, en const char ça marche, mais pas en const wchar_t, sauf si j'encode le fichier en UTF-8, mais sous windows quand on encode en UTF-8 cet abruti veut souvent un BOM et le BOM fait aussi planter le compilateur qui ne le reconnait pas non plus. Je suis obligé d'utiliser la forme \xNN. Forme \xNN qui est elle même merdique puisque, en plus d'être super lisible, elle ne marche pas comme prévu si le caractère qui suit est un hex digit valide, p.ex. L"t\xE9l\xE9chargement" ne donne pas "téléchargement" mais "tél?hargement" avec le "?" remplacé par un caractère dont la valeur est 0xE9C. LE parsing de cette forme est ultra con et continue tant qu'il y a un hex digit valide. Au final je me retrouve avec L"t\xE9l\xE9" L"chargement" dans le code. C'est vrai que là il y a un gros problème. Je n'ai pas l'impression que la forme \uNNNN populaire dans d'autres langages ne fonctionne en C++, et de toute façon ça ne change pas la lisibilité.

Ce serait sûrement plus simple si j'utilisais VS à la place de MinGW, mais je trouve que c'est une usine à gaz (rien ne sert de troller, c'est un autre sujet).

L'avantage de ce gros bordel c'est que ça encourage à utiliser immédiatement un système d'internationalisation… j'utilise souvent des bêtes fichiers clé=valeur chargés dans une unordered_map<string,tstring>, mais pour faire plus poussé on a gettext. Sous windows on peut stocker aussi les chaînes internationalisées dans les ressources intégrées à l'exécutable, mais j'ai pas encore pigé comment il fallait faire exactement malgré plusieurs lectures de la doc MSDN. ET le compilateur de ressources de MinGW (windres) est parfois un peu bancal.

Ça, c'est encore un autre problème : le compilateur utilise un encodage propre en interne depuis lequel il va convertir vers l'encodage du système (aussi bien pour les caractères larges que pour les caractères classiques). Or, ceci implique une conversion de l'encodage du fichier texte vers celui utilisé en interne par le compilateur et c'est là qu'est l'os. GCC suppose que le fichier est encodé en UTF-8 et utilise celui-ci en interne. Si tu souhaites utiliser un autre encodage pour ton fichier texte, tu dois préciser à GCC celui que tu utilises à l'aide de l'option -finput-charset.

De même, tu peux spécifier quel encodage sera utilisé pour les caractères et les caractères larges à l'aide des options -fexec-charset et -fwide-exec-charset (les conversions possibles dépendent de la bibliothèque iconv).

Ça, c'est encore un autre problème : le compilateur utilise un encodage propre en interne depuis lequel il va convertir vers l'encodage du système (aussi bien pour les caractères larges que pour les caractères classiques). Or, ceci implique une conversion de l'encodage du fichier texte vers celui utilisé en interne par le compilateur et c'est là qu'est l'os. GCC suppose que le fichier est encodé en UTF-8 et utilise celui-ci en interne.

Bon à savoir pour les options de charset. Mais le compilateur n'est même pas cohérent avec lui-même en fait; je m'explique :

Si j'écris printf("hé ho"); dans une source encodée en Windows-1252, ça compile et ça fonctionne très bien (à condition que le charset de la console soit bien paramétré en 1252, ce qui n'est pas la configuration par défaut (par défaut c'est le 850 qui est une réminiscence du DOS)).

Par contre wprintf(L"hé ho"); est refusé et ne compile même pas. Le message d'erreur ressemble à "ILlegal character sequence".

Dans un cas il accepte très bien mon Windows-1252 sans broncher, et dans l'autre il veut absolument de l'UTF-8. IL n'y a pas de logique…

Mais bon depuis que j'externalise toutes mes strings dans des fichiers clé=valeur encodés en UTF-8 (et que j'ignore la première ligne à cause du BOM), je n'ai plus de problèmes

Tu as bien utilisé l'option -finput-charset afin d'indiquer l'encodage du fichier et, si oui, tu as bien spécifié le bon encodage ?

Un peu tard (je sais) mais je voulais rebondir sur ce point :

à mes yeux, les threads n'ont pas à être traités dans la norme d'un langage, il s'agit de quelque chose qui doit être régler par la bibliothèque d'un système d'exploitation

C'est juste faux et je t'invite à lire Threads Cannot be Implemented as a Library de Hans J. Boehm pour voir en quoi c'est faux. Il utilise spécifiquement le C et pthread pour illustrer les problèmes.

Pour info, ce dernier participa grandement à la définition du modèle mémoire du C++

Merci pour cet article.

à mes yeux, les threads n'ont pas à être traités dans la norme d'un langage, il s'agit de quelque chose qui doit être régler par la bibliothèque d'un système d'exploitation

C'est juste faux et je t'invite à lire Threads Cannot be Implemented as a Library de Hans J. Boehm pour voir en quoi c'est faux. Il utilise spécifiquement le C et pthread pour illustrer les problèmes.

Tout d'abord, je note que l'auteur ne semble pas aussi catégorique que toi.

Library-based approaches to concurrency normally require a very disciplined style of synchronization by multi-threaded programs. Although we agree that this is appropriate for perhaps 98% of uses, we argue that it eliminates some low-level programming techniques which, in some cases, may be essential for obtaining any performance benefit from multiple processors.

Ensuite, ce que l'auteur présente sont des problèmes liés aux optimisations potentielles des compilateurs. À mes yeux, cela ne démontre en rien l'utilité de définir les threads au sein du langage C, mais simplement la nécessité de pouvoir indiquer des portions de code où aucune optimisation ne doit être réalisée, ce qui est déjà en grande partie le cas grâce au qualificateur de type volatile.

Ainsi, le troisième exemple qu'il donne à la page 6 peut être entièrement résolu en qualifiant le type de la variable x comme volatile. D'ailleurs, le sens de ce mot-clé est très bien expliqué par la norme C.

S'agissant de variable partagées, nous sommes bien dans le cas où la valeur de celles-ci peut être modifiée d'une manière que le compilateur ne peut pas prévoir.

Enfin, je remarque que l'auteur pinaille franchement sur les termes de la norme POSIX. S'il est vrai qu'elle ne défini pas ce qu'elle entend par « un accès ou une écriture dans une même zone mémoire », il me semble évident qu'en cas de doute, il est préférable de considérer celle-ci comme la plus étendue possible. Dès lors, je trouve cela discutable de présenter des cas de concurrences avec des structures et, à plus forte raison, avec des champs de bits, en arguant qu'un verrou ne concernerait qu'un seul champ.

A mon avis, la question des threads est essentielle à traiter dans le langage pour une raison très simple : la définition du modèle mémoire. Sans celui-ci, on ne peut pas faire de raisonnement sur le programme, pour de la preuve ou autre.

PS : Concernant volatile et le multithread :

A noter que le modèle mémoire de C++11/C11 est plutôt bien foutus (en tout cas si l'on compare à d'autres langages), même s'il reste un gros soucis pour pouvoir le rendre intégralement formel et utilisable.

Et donc je rejoints complètement @Praetonus sur le point du modèle mémoire. Sa définition fait profondément partie de la définition du multi-threading dans le langage. Et on ne peut pas se passer d'un modèle mémoire précis dans un langage qui a vocation à accepter le bas niveau.

À mes yeux, la question des fils d'exécution est extérieure au langage. Foncièrement, il s'agit de questions relatives aux intéractions entre deux programmes, elles relèvent donc à mon sens du système d'exploitation et non d'un quelconque langage. C'est au système d'exploitation de préciser comment deux ou plusieurs programmes communiquent et intéragissent entre eux.

L'objectif du qualificateur volatile n'est pas d'assurer la synchronisation entre deux fils d'exécution ou l'atomicité d'une opération, ce sont les fonctions de la bibliothèque Pthread qui s'en chargent, mais bien de signaler au compilateur de ne pas optimiser l'accès aux objets qualifiés comme tel, leur valeur pouvant être modifiée via un autre fil.