syntaxe pour compilation conditionnelle ?

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:

---

1 2	#ifndef FICHIER_H #define FICHIER_H

---

ou encore

Code:

---

1 2	#ifndef _FICHIER_H_INC #define _FICHIER_H_INC

---

ou bien alors

Code:

---

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

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

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.

Bonjour,

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

Citation:

---

Envoyé par tintin72

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:

---

1 2	#ifndef FICHIER_H #define FICHIER_H

---

---

Bien mais

Code:

---

1 2 3

#ifndef H_FICHIER #define H_FICHIER

---

est encore mieux.

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

Citation:

---

Envoyé par Emmanuel Delahaye

Bien mais

Code:

---

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:

---

1 2	#ifndef FICHIER_H

---

qui a recemment remplace le trop long

Code:

---

1 2	#ifndef FICHIER_INCLUDED

---

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

Citation:

---

Envoyé par DaZumba

Citation:

---

Envoyé par Emmanuel Delahaye

Bien mais

Code:

---

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:

---

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é).

Citation:

---

Envoyé par Emmanuel Delahaye

(...) 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 !

Avec

Code:

---

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.

Citation:

---

Envoyé par Ti-R

Code:

---

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...

Citation:

---

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

Citation:

---

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é