[Kos-dev] Extrait de la fclc
kos-dev@enix.org
kos-dev@enix.org
29 Jan 2002 15:27:33 +0100
Salut,
voici un extrait de la FCLC FAQ :
**** DEBUT ****
16.5 Pourquoi ne pas mettre de `_' devant les identifiants ?
Well well well, ce n'est pas si facile.
=20=20=20=20
Les vrais identificateurs r=E9serv=E9s sont :
=20=20=20=20
- les mots cl=E9s tels que if, for,
switch, long, ...
- les identificateurs commen=E7ant par deux `_'
- les identificateurs commen=E7ant par un `_'
suivi d'une lettre majuscule.
=20=20=20=20
Ensuite, il y a les headers standards et la biblioth=E8que. Les
headers sont libres d'utiliser des identificateurs commen=E7ant par
un `_' et suivis d'une lettre minuscule, comme `_liste', mais
c'est pour d=E9finir quelque chose qui a un =AB file scope =BB,
c'est-=E0-dire une port=E9e globale =E0 la =AB translation unit =BB=
(le
fichier source C et les fichiers qu'il inclut). Donc, globalement,
on ne doit pas s'en servir pour d=E9finir quelque chose qui a ce =AB
file scope =BB.
=20=20=20=20
=C7a veut dire quoi ? Que les choses suivantes sont interdites :
=20=20=20=20
typedef int _foo;
struct _bar {
int x;
char * y;
};
void _f(void);
=20=20=20=20
En revanche, les choses suivantes sont autoris=E9es :
=20=20=20=20
void f(int _x[]) {
typedef int _foo;
struct _bar {
int x;
char *y;
};
extern void _g(void);
}
struct qux {
long _truc;
};
=20=20=20=20
J'attire l'attention du public =E9bahi sur les quatre points
suivants :
- En d=E9finissant des identificateurs =E0 port=E9e r=E9duite (bl=
oc,
prototype, fonction), on peut masquer des identificateurs d=E9finis
par les headers standards, identificateurs qui pouvaient
intervenir dans des macros d=E9finies dans lesdits headers ; comme
toutes les fonctions standards peuvent =EAtre surcharg=E9es par des
macros, =E0 l'int=E9rieur d'un bloc o=F9 on a jou=E9 =E0 d=E9finir =
un
identificateur de type _foo, toute utilisation d'une
facilit=E9 fournie par un header peut d=E9clencher un =AB undefined
behaviour =BB (par exemple, l'ordinateur utilise spontan=E9ment son
modem pour t=E9l=E9phoner =E0 la belle-m=E8re du programmeur et l'i=
nviter
=E0 venir d=EEner =E0 la maison).
- Le extern void _g(void); explicite le fait que la
restriction est sur le scope et pas le linkage. Bien entendu, il
faut que la fonction _g() soit d=E9finie quelque part, avec
un external linkage, ce qui ne peut pas se faire en C
standard. Donc cette d=E9claration, quoique valide, doit avoir un
pendant dans une autre translation unit, qui ne peut pas =EAtre
fabriqu=E9 de fa=E7on standard. Pour compl=E9ter, rajoutons que la
d=E9finition n'a besoin d'exister que si on se sert effectivement de
la fonction. Donc on est en fait autoris=E9 =E0 faire une d=E9clara=
tion
inutile qui pourrait faire planter des impl=E9mentations non
conformes mais courantes. How useful.
- Quand bien m=EAme on aurait le droit, rares sont les
impl=E9mentations compl=E8tement conformes de ce point de vue. Par =
pur
pragmatisme, on =E9vite donc de jouer avec des identificateurs
commen=E7ant par un `_' suivi d'une lettre minuscule.
- Chaque header apporte ses propres restrictions ; par
exemple, <ctype.h> peut d=E9clarer n'importe quel
identificateur qui commence par "is" ou "to" suivi d'une lettre
minuscule. Ces identificateurs sont r=E9serv=E9s pour ce qui est de
l'external linkage, ce qui veut dire que m=EAme si on n'inclut pas
<ctype.h>, on ne doit pas d=E9finir, entre autres, de
variable globale "iszoinx" qui ne soit pas prot=E9g=E9 par le mot c=
l=E9
static.
**** FIN ****
Il me semble qu'on utilise un peu partout des noms de fonctions en _*,
nan ?
Thomas
--=20
PETAZZONI Thomas - thomas.petazzoni@enix.org - UIN : 34937744
(Perso) http://www.enix.org/~thomas/
(KOS) http://kos.enix.org/=20
(Club LinUT) http://club-linut.enix.org