Discussion :

[adiks]

Bonsoir à tous,

j'aimerai connaître la particularité des variables dont le nom commence par un caractère under score "_" en C

Y a t'il un but particulier qui pousse certains développeur à utiliser ce type de nom pour leurs variables ?

Merci d'avance pour vos différentes réponses

[Jean-Marc.Bourguet]

En gros, les identificateurs commencant par un underscore et ceux contenant deux underscore consecutif(*) sont reserves pour l'implementation(**). Ils ne faut donc pas les utiliser. L'objectif est que de donner aux implementations la possiblilite d'utiliser des identificateurs prives qui ne risquent pas d'entrer en conflit avec ceux des utilisateurs.

Probleme, certains ont ete voir comment les implementations etaient programmees et ont copie leur style en utilisant des identificateurs commencant par des underscores. Et en risquant ainsi le conflit avec les implementation.

(*) Je sais, c'est pas le cas en C mais c'est le cas en C++ et en pratique il vaut mieux les eviter aussi.
(**) Plus en details, suivant la portee consideree, certains identificateurs peuvent ne pas etre reserves. Je me refuse a apprendre ces details.

[Kirilenko]

Salut,

Pour être un petit peu plus précis (simple complément de réponse), la norme du langage C exige que les identificateurs commençant par un underscore et une lettre majuscule ou commençant par deux underscores sont réservés, tout comme les identificateurs qui commencent par un underscore et qui ont une portée au niveau du fichier.

— All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
— All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.

Généralement, cela implique que ceux-ci sont potentiellement utilisés par la bibliothèque standard de C. Toute utilisation de tels identificateurs peut engendrer une collision. Quelques exemples suivent.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* 
 * Interdit car `struct _s' a une portée au niveau du fichier. 
 */
struct _s {  
 
	/* 
	 * Interdit car `__n' commence par deux underscores. 
	 */
	int __n; 
 
	/* 
	 * Interdit car `_N' commence par un underscore et une lettre 
         * majuscule. 
	 */
	int _N;  
 
	/*
	 * Autorisé car `_n' n'a pas une portée au niveau du fichier.
	 */
	int _n;
};

[adiks]

Je vous remercie pour ces éclaircissements. donc en gros les programmeurs qui postent les codes de leurs tutos avec de tel identificateur, sont des hors la loi !

[Obsidian]

Salut,

Pour être un petit peu plus précis (simple complément de réponse), la norme du langage C exige que les identificateurs commençant par un underscore et une lettre majuscule ou commençant par deux underscores sont réservés, tout comme les identificateurs qui commencent par un underscore et qui ont une portée au niveau du fichier.

À noter également que le passage que tu cites est tiré de C11, qui est une norme toute récente. C'est surtout C99 et C89 qui font encore référence aujourd'hui, mais cela reste une bonne idée de se conformer à cette règle en particulier.

[Jean-Marc.Bourguet]

À noter également que le passage que tu cites est tiré de C11, qui est une norme toute récente. C'est surtout C99 et C89 qui font encore référence aujourd'hui, mais cela reste une bonne idée de se conformer à cette règle en particulier.

De mémoire, ça n'a pas changé depuis C90.

[Kirilenko]

À noter également que le passage que tu cites est tiré de C11, qui est une norme toute récente. C'est surtout C99 et C89 qui font encore référence aujourd'hui, mais cela reste une bonne idée de se conformer à cette règle en particulier.

En effet, et cela est volontaire : je me rapporte toujours à la norme la plus récente quand il s'agit de détails techniques, au cas où les spécifications aient changé, justement. Même si la C11 n'est pas actuellement implémentée en masse, les points un peu plus sombres des normes précédentes sont ainsi corrigés, et l'ambiguïté est réduite.

Question de goût, après, mais, quand j'incorporais des citations de C89 à mes messages sur StackOverflow par exemple, on se moquait un peu de moi ! Au final, je ne trouve pas ça si mal.

Histoire d'optimiser et de clore cette discussion, voici le passage de la norme C89 à ce sujet.

All external identifiers that begin with an underscore are reserved. All other identifiers that begin with an underscore and either an upper-case letter or another underscore are reserved.

[Obsidian]

En effet, et cela est volontaire : je me rapporte toujours à la norme la plus récente quand il s'agit de détails techniques, au cas où les spécifications aient changé, justement. Même si la C11 n'est pas actuellement implémentée en masse, les points un peu plus sombres des normes précédentes sont ainsi corrigés, et l'ambiguïté est réduite.

Oui, mais n'oublie pas que la norme n'est pas qu'une somme de restrictions. C'est aussi et souvent des fonctionnalités supplémentaires qui, parfois, impliquent beaucoup d'infrastructures sous-jacentes voire une « formation » des développeurs à ces nouveautés.

Par exemple, C11 propose « #include <thread.h> », ce qui est quand même lourd de conséquences, car toutes les architectures ne sont pas en mesure de proposer ces services. Heureusement, les gens qui ont planché dessus le savent et ont introduit _ _STDC_NO_THREADS_ _, qui doit être définie par le compilateur le cas échéant.

Il en reste que, dans certains cas, deux versions de la norme d'un même langage peuvent parfois être considérées comme deux langages différents, comparables (mais dans une moindre mesure) à ce qui sépare le C et le C++.