Pourquoi les mots-clés laids du C11?

Je lis actuellement un projet de spécification C11. Les nouveaux mots clés introduits: _Bool, _Alignof, _Atomictous ressemblent à des extensions personnalisées, au lieu de mots clés réservés standard comme struct, union, int.

Je me rends compte que la norme consiste essentiellement en extensions standardisées ... mais quand même, c'est affreux! Peut-être que nous finirons bientôt par __Long_Long_Reallylong_Integer_MSVC_2020_tramper dans la norme!

La compatibilité descendante du code non standard est-elle la seule raison du nouveau style des mots-clés?

c keywords

— Vorac
source

Non, je ne m'inquiéterais pas des types très longs comme ça. Le nombre de lettres et de combinaisons de chiffres de _, az, AZ et 0-9 signifie qu'ils seraient probablement courts et difficiles à retenir à la place.

— Neil

Un synonyme plus joli pour chaque mot clé est souvent défini dans le fichier d'en-tête de bibliothèque standard correspondant. Par exemple, tout <stdbool.h>fichier d'en-tête d'implémentation C11 doit inclure une macro de préprocesseur telle que #define bool _Bool. Il s'agit d'une solution intéressante car elle conserve la compatibilité descendante, mais permet à tout nouveau code, qui inclut le nouveau fichier d'en-tête, d'utiliser la syntaxe la plus attrayante.

— andrew.punnett

Réponses:

J'imagine que la rétrocompatibilité avec du code parfaitement standard est une raison plus importante.

Si vous ajoutez un mot-clé qui aurait pu être utilisé comme identifiant légitime dans le code précédent, vous créez une tonne de douleur, d'erreurs subtiles possibles, en particulier en C, un langage avec des règles d'analyse en quelque sorte compliquées.

Si ces identifiants ont été utilisés comme interface publique quelque part, vous alourdissez tous les utilisateurs de ces bibliothèques malheureuses, qui pourraient ne pas utiliser C du tout, mais appelez la bibliothèque à partir de Ruby, ou Python, etc.

C'est pourquoi les nouveaux mots clés ressemblent moins à de beaux mots qu'à des hacks bolt que les gens ont moins de chances d'utiliser déjà dans un autre but.

— 9000
source

Il convient de souligner que la question concernait le C et non le C ++ et non son importance. Votre réponse couvre la raison pour laquelle un nouveau type supoprted serait nommé quelque chose pour éviter d'utiliser un conflit avec un type personnalisé Booldans le code hérité qui a été largement accepté comme étant un booléen mais jamais en fait partie de la norme C, donc l'hypothèse n'est pas sûre de faire.

— Ramhound

@Ramhound, à mon humble avis boolserait plus dans l'esprit de C. Aussi, je ne suis pas complètement convaincu par cette réponse, car des mots laids pourraient également avoir été utilisés par du code non standard. Et changer le style des mots rend les mots standard plus difficiles à reconnaître en un coup d'œil.

— Vorac

@Vorac: Le problème est que s'il boolétait ajouté inconditionnellement à la langue, alors tous les projets qui ont leur propre version (parfaitement légitime) de boolcesseraient de compiler. Cela nuirait gravement à l'acceptation de la révision linguistique. C'est la raison pour laquelle tous les nouveaux identifiants sont extraits de l'ensemble réservé (commençant ainsi par _[capital]). Comme il y avait également une forte demande pour boolelle-même, cela a été ajouté comme typedef _Bool booldans <stdbool.h>.

— Bart van Ingen Schenau

@BartvanIngenSchenau - qui permet aux utilisateurs de remplacer leur propre typedef d'une valeur booléenne par un contenu dans stdbool.hou de mettre à jour leur propre typedef vers le nouveau type pour prendre en charge leur code hérité.

— Ramhound

@Ramhound - les personnes dont les variables entrent en conflit avec les nouveaux mots clés C11 peuvent également "Alors ne l'utilisez pas?". Il existe un indicateur de compilation std = xxx pour éviter tout conflit avec les nouvelles normes de langage.

— Scooter

Les noms commençant par un trait de soulignement et une lettre majuscule (et tout ce qui a un double trait de soulignement) étaient réservés à l'implémentation du compilateur / bibliothèque standard dans les normes précédentes.

À partir des identificateurs réservés de C89 et C99:

Sont également réservés à l'implémenteur tous les identifiants externes commençant par un trait de soulignement et tous les autres identifiants commençant par un trait de soulignement suivi d'une lettre majuscule ou d'un trait de soulignement.

Donc, en théorie, ces nouveaux mots-clés ne devraient pas être utilisés dans aucun code écrit auparavant et cela conduit à une meilleure compatibilité descendante que n'importe quel nom simple, ce qui est probablement la seule raison.

— Dotti
source

Vous devez citer et éventuellement lier ou nommer la section des normes appropriées, afin que d'autres puissent vérifier rapidement votre déclaration. Cela améliorera votre réponse.

— SpaceTrucker