Discussion :

[tintin72]

Bonjour,

Je voudrais savoir quel est la syntaxe exacte lorsqu'on veut éviter les inclusions multiple de fichier. J'ai en effet vu plusieurs versions.
exemple pour un fichier : fichier.h

Code :

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

1
2
#ifndef   FICHIER_H
#define  FICHIER_H

ou encore

Code :

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

1
2
#ifndef   _FICHIER_H_INC
#define  _FICHIER_H_INC

ou bien alors

Code :

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

1
2
#ifndef   __FICHIER__
#define  __FICHIER__

Je ne sais donc pas quel est la bonne syntaxe à adopter ni quel est la
signification (s'il y en a une) au niveau de la position des underscores.

Pour l'instant j'utilise la syntaxe du 1er exemple (qui me parait + logique)
mais si quelqu'un pouvait m'expliquer les raisons de toutes ces différentes syntaxes ce serait sympa ;-)

Merci

Tintin72

[le y@m's]

techniquement ya pas de differences:
mais je sais que certaines syntaxes sont "reservee", malheuresement je n'en sais pas plus

[DaZumba]

La seule regle est d'eviter le underscore au debut (genre _MATH_H). L'implementation se reserve ces identifiants. Apres, on fait ce que l'on veut, du moment que la macro est unique.

[gangsoleil]

Bonjour,

Je conseil la lecture de ceci : http://emmanuel-delahaye.developpez.com/codage.htm
Regarder le paragraphes sur les fichier d'en-têtes

[Emmanuel Delahaye]

Je voudrais savoir quel est la syntaxe exacte lorsqu'on veut éviter les inclusions multiple de fichier. J'ai en effet vu plusieurs version.
exemple pour un fichier : fichier.h

Code :

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

1
2
#ifndef  FICHIER_H
#define  FICHIER_H

Bien mais

Code :

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

1
2
3
 
#ifndef  H_FICHIER
#define  H_FICHIER

est encore mieux.

http://emmanuel-delahaye.developpez....nom_underscore
http://emmanuel-delahaye.developpez....ganiser_source

[DaZumba]

Bien mais

Code :

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

1
2
3
 
#ifndef  H_FICHIER
#define  H_FICHIER

est encore mieux.

Je te crois, mais il y a une raison objective pour vouloir mettre le "H_" devant ? Personnellement, j'utilise

Code :

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

1
2
 
#ifndef FICHIER_H

qui a recemment remplace le trop long

Code :

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

1
2
 
#ifndef FICHIER_INCLUDED

Et je ne vois rien de reprehensible la-dedans...

[Emmanuel Delahaye]

Bien mais

Code :

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

1
2
3
 
#ifndef  H_FICHIER
#define  H_FICHIER

est encore mieux.

Je te crois, mais il y a une raison objective pour vouloir mettre le "H_" devant ?

Oui, c'est pour éviter

Code :

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

1
2
3
/* err.h */
#ifndef ERR_H
#define ERR_H

qui briserait la regle qui dit que les identificateurs commençant par E suivi d'une majuscule sont réservées à l'implémentation. (Les constantes 'erreurs', précisément, c'est à dire les valeurs définies de errno).

• Certains sont définies par le langage C
• D'autres par POSIX.1
• D'autres enfin par le compilateur (à éviter pour des problèmes de portabilité).

[DaZumba]

(...) qui briserait la regle qui dit que les identificateurs commençant par E suivi d'une majuscule sont réservées à l'implémentation.

J'ignorais cette regle. Merci pour cela !

[Ti-R]

Avec

Code :

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

1
2
#ifndef __FICHIER__ 
#define __FICHIER__

Je n'ai pas encore eu de problèmes.
Mais biensur à éviter avec des noms "courts"

__ERR__
ou __C__ ou autres... cela parait logique !
Idem pour la méthode à Emmanuel

Si tu fais H_ERR ou H_FILE ou je ne sais quoi, c'est certain que tu auras un problème un moment ou un autre.

Plus c'est cour, plus il y a de chance que cela soit déjà défini quelque part.

J'utilise le nom de la lib en plus dedans pour être sur de sur
donc généralement __FICHIERGD__
si le nom de la lib est GD, mais tu peux faire __FICHIER_GD__
ou encore H_FICHIER_GD ou H_GD_FICHIER. Enfin tu as le choix, le but étant de ne pas avoir 2 fois le même pour toi et en incluant les projets d'autres personnes.

[Emmanuel Delahaye]

Code :

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

1
2
#ifndef __FICHIER__ 
#define __FICHIER__

Je n'ai pas encore eu de problèmes.

Comment tu le sais ? Des __xxx__ il y en plein les fichier .h des implémentations. C'est fait exprès pour que ça ne clashe pas avec l'utilisateur. Si l'utilisateur utilise les mêmes __xxx__, , le comportement est indéfini. Tout peut arriver, y compris un bug silencieux qui sortira le jour de la démo...

Mais biensur à éviter avec des noms "courts"

Si tu fais H_ERR ou H_FILE ou je ne sais quoi, c'est certain que tu auras un problème un moment ou un autre.

Plus c'est cour, plus il y a de chance que cela soit déjà défini quelque part.

Ca, c'est un autre problème.

http://emmanuel-delahaye.developpez....ganiser_source

J'utilise le nom de la lib en plus dedans pour être sur de sur
donc généralement __FICHIERGD__
si le nom de la lib est GD, mais tu peux faire __FICHIER_GD__
ou encore H_FICHIER_GD ou H_GD_FICHIER. Enfin tu as le choix, le but étant de ne pas avoir 2 fois le même pour toi et en incluant les projets d'autres personnes.

Non, tu n'as pas le choix. Les __xxx et les _[A-Z]xxx sont réservés à l'implémentation. C'est pourtant clair, non ?

__FICHIERGD__ -> interdit à l'utilisateur
H_FICHIER_GD -> autorisé
H_GD_FICHIER -> autorisé