J'ai une certaine confusion pour le contenu des noms de variables dans K & R C. Texte original comme ci-dessous:
Au moins les 31 premiers caractères d'un nom interne sont significatifs. Pour les noms de fonction et les variables externes, le nombre peut être inférieur à 31, car les noms externes peuvent être utilisés par les assembleurs et les chargeurs sur lesquels le langage n'a aucun contrôle. Pour les noms externes, la norme garantit l'unicité uniquement pour 6 caractères et une seule casse. Les mots clés comme if, else, int, float, etc. sont réservés: vous ne pouvez pas les utiliser comme noms de variables. Ils doivent être en minuscules. Il est sage de choisir des noms de variables qui sont liés à l'objectif de la variable et qui ne risquent pas d'être mélangés typographiquement. Nous avons tendance à utiliser des noms courts pour les variables locales, en particulier les index de boucle, et des noms plus longs pour les variables externes.
Ce qui m'a dérouté, ce sont les noms externes, la norme garantit l'unicité uniquement pour 6 caractères et une seule casse. Cela signifie-t-il que pour les noms externes, seuls les 6 caractères principaux sont valides et que les caractères restants sont tous ignorés? Par exemple, nous avons défini deux variables externes myexvar1 et myexvar2, le compilateur traitera ces deux variables comme une seule? Si cela est vrai, pourquoi ils nous conseillent d'utiliser des noms plus longs pour les variables externes?
4 Réponses :
Cela signifie-t-il que pour les noms externes, seuls les 6 caractères principaux sont valides et que les caractères restants sont tous ignorés? Par exemple, nous avons défini deux variables externes myexvar1 et myexvar2, le compilateur traitera ces deux variables comme une seule?
Oui, c'était vrai en 1990. Ou plutôt, 6 caractères de tête uniques d'identificateurs externes étaient ce que la norme C90 avait défini comme la limite minimum pour un compilateur. C'était bien sûr de la folie - c'est pourquoi cette limite a été augmentée à 31 en C99.
En pratique, la plupart des compilateurs C90 avaient au moins 31 caractères uniques pour les identifiants internes et externes.
Si cela est vrai, pourquoi ils nous conseillent d'utiliser des noms plus longs pour les variables externes?
Je ne sais pas s'ils le conseillent. Mais le style de codage utilisé dans K&R est souvent horrible, donc ce n'est certainement pas un livre que vous devriez consulter pour obtenir des conseils sur le style de codage.
En C moderne, il est nécessaire (C17 5.2.4.1) que nous ayons:
63 caractères initiaux significatifs dans un identifiant interne ou un nom de macro
31 caractères initiaux significatifs dans un identifiant externe
Alors ne vous inquiétez pas trop des limitations auxquelles les dinosaures étaient confrontés, mais suivez la norme moderne C.
Comme indiqué dans une autre réponse, même la restriction de 31 caractères initiaux significatifs pour les identificateurs externes est répertoriée comme obsolète, ce qui signifie que cela pourrait être encore augmenté, à 255, dans les futures normes.
À vrai dire, K&R est assez vieux, donc je suppose que les choses ont changé depuis. Je ne sais vraiment pas pourquoi il donne exactement 6 caractères ici:
Pour les noms externes, la norme garantit l'unicité uniquement pour 6 caractères et une seule casse.
Mais vous devez comprendre que tout ce que le compilateur fait est de traduire une unité de traduction (généralement un fichier * .c ) en un fichier objet ( * .o ). C'est ça. Le compilateur ne produit pas de programme prêt à être exécuté.
Ces fichiers objets peuvent contenir des références à des symboles non résolus se trouvant dans d'autres fichiers objets ainsi qu'un tableau de leurs propres symboles externes, ceux qu'ils fournissent pour être référencés de l'extérieur. Les symboles ont des noms textuels, qui sont les noms que vous avez donnés à vos variables externes.
Les éditeurs de liens et les chargeurs dynamiques doivent encore faire leur travail pour créer le programme et le faire fonctionner. En cours de route, ils doivent résoudre tous les symboles non résolus, de sorte qu'ils effectuent une recherche textuelle de ces symboles dans des fichiers objets. Les éditeurs de liens et les chargeurs ne sont pas des compilateurs. Ils pourraient avoir leurs propres règles sur le traitement de ces noms (à l'époque de K&R, je suppose). C'est ce que c'est ...
car les noms externes peuvent être utilisés par des assembleurs et des chargeurs sur lesquels le langage n'a aucun contrôle.
... c'est environ.
De nos jours, cependant, toutes vos préoccupations K&R semblent obsolètes et hors de propos. Choisissez une nouvelle norme à suivre.
Cela est dû au contexte historique concernant la longueur des symboles exportés vers l'éditeur de liens du système.
Je cite The New C Standard - An Economic and Cultural Commentary .
Les valeurs de 6 et 10 ont été choisies pour que les encodages \ u1234 et \ U12345678 pourrait être utilisé.
La limite de six caractères significatifs de Fortran a été suivie par de nombreux fournisseurs de liens depuis longtemps. Le besoin d'identifiants plus longs pour prendre en charge la modification des noms en C ++, la plupart des éditeurs de liens modernes prend en charge de nombreux caractères plus significatifs dans un identifiant externe.
Implémentations courantes
Historiquement, le nombre de caractères dans un identifiant externe dépendait du comportement du éditeur de liens fourni par le fournisseur hôte. Ce n'est que depuis le succès de MS-DOS les développeurs s'habituent à ce que les fournisseurs de traducteurs fournissent leurs propres éditeur de liens. Auparavant, la plupart des éditeurs de liens étaient généralement fournis par le matériel vendeur. Le monde mainframe avait tendance à être régi par les exigences de Fortran, qui avait six personnages significatifs dans un interne ou identifiant externe. Dans cet environnement, il n'était pas toujours possible de remplacer l'éditeur de liens système par un autre supportant personnages. L'importance de l'environnement mainframe a diminué dans Années 90. Dans les environnements modernes, il est très souvent possible d'obtenir liens alternatifs.
Le principal problème était donc de pouvoir relier entre elles les bibliothèques compilées en C avec les bibliothèques compilées en Fortran, et Fortran a imposé la limite de 6.
Vous pouvez en savoir plus à la référence donnée.
C'est un héritage du passé qui n'est plus important. Aucun compilateur d'aujourd'hui n'a ces limites, et c'était quelque chose qui date de l'époque où l'ancien Unix a été créé. Les raisons étaient (alors et aujourd'hui) les limites imposées par le compilateur aux noms dans la table des symboles (31) et la limite utilisée par l'éditeur de liens (6) à cette époque.
Mais ce n'est plus applicable. Au moins, vous pouvez être sûr que les éditeurs de liens d'aujourd'hui permettront à différents identifiants de se déclarer différents avec au moins un préfixe commun de longueur 100.
En 2019, la norme à laquelle il faut se soucier sera probablement C11, alors lisez n1570 . Sur la plupart des implémentations d'aujourd'hui, tous les caractères d'un nom externe sont pratiquement significatifs. Sur mon système Linux, juste pour le plaisir, j'ai essayé un symbole avec un million de lettres. Tous sont significatifs dans la pratique.
La façon dont je lis ceci, les "noms plus longs pour les variables externes" est en contraste avec les "noms courts pour les variables locales, en particulier les indices de boucle". Ainsi, par exemple, vos itérateurs auront des noms comme
iet les variables externes auront des noms plus longs que cela.Notez que la variable externe peut ne pas provenir d'une chaîne d'outils différente mais d'un module C différent qui est lié par les mêmes règles.