Problème des #ifndef dans les en-têtes.

Version imprimable

30/09/2012, 10h42
Neckara

Problème des #ifndef dans les en-têtes.

Bonjour,

Ce n'est pas uniquement un problème de C++ mais comme je compile avec g++, je me permet de poster ici.

J'ai récemment bloqué sur un petit problème pendant pas mal de temps :
L'un de mes header portait le même nom ( Semaphore.h) qu'un header de la librairie standard du C qu'il incluait (semaphore.h).
Ainsi SEMAPHORE_H était défini et le contenu de semaphore.h était vide.

Que faire dans ce cas là?
Je pourrais certes changer le define SEMAPHORE_H dans mon header par define SEMAPHORE_H2.

Mais si je ne peux pas modifier le define ? Par exemple si j'inclus deux bibliothèques, chacune ayant respectivement un fichier init.h et Init.h.

Comment éviter ce type de problème ?
Un header d'une bibliothèque que j'utilise peut très bien inclure un header portant le même nom qu'un autre de mes header et là ça sera beaucoup plus dur de trouver l'origine du problème.

EDIT : J'ai regardé un peu trop vite, ils définissent _SEMAPHORE_H.
Mais la question reste entière pour deux bibliothèques ayant deux fichiers de même noms.
Pour les curieux, mon problème venait de QtCreator qui incluait mon propre semaphore.h...

Quand tu mixes ainsi deux bibliothèques qui sont incompatibles en terme de macro, il n'y a pas de belle solution...
Code:

1 2 3 4 #include "libAWithMacroTOTO.h" #undef TOTO #include "libBWithMacroTOTO.h" // LibB a redéfini TOTO, et donc devrait protéger contre la réinclusion de A et de B...

Je vois.
Par contre, l'inclusion peut se faire sur des header différents.
Dans ce cas là autant créer deux nouveaux header ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 // newLibA.h #ifndef NEWLIBA_H #define NEWLIBA_H #undef TOTO #include<libA.h> #undef TOTO #endif // newLibB.h #ifndef NEWLIBB_H #define NEWLIBB_H #undef TOTO #include<libB.h> #undef TOTO #endif

Citation:
Envoyé par Neckara
Je vois.
Par contre, l'inclusion peut se faire sur des header différents.
Dans ce cas là autant créer deux nouveaux header ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 // newLibA.h #ifndef NEWLIBA_H #define NEWLIBA_H #undef TOTO #include<libA.h> #undef TOTO #endif // newLibB.h #ifndef NEWLIBB_H #define NEWLIBB_H #undef TOTO #include<libB.h> #undef TOTO #endif
Attention, ça reste sale, et tu risques d'avoir des soucis... Imagine que tu inclues directement un fichier de libA, parce qu'il n'a pas l'air d'y avoir de conflits. Mais ce fichier inclue lui même indirectement <libA.h> (et défini TOTO). Si par la suite tu inclues <newLibA.h>, tout ce qui est dans <libA.h> sera défini deux fois (remarque : Le code que j'ai proposé souffre du même problème).

Sacré casse-tête...
Encore heureux que les compilateurs mette un warning quand on a une redéfinition de macro ( je viens de tester).

Et si on encapsule la libA et la libB séparément ?
Mais dans certains cas ça peut être laborieux...

Et sinon si on fait :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#ifdefine MODE_LIBA
    #ifdefine TOTO_A
          #define TOTO
     #else
          #undef TOTO
     #endif
     #include<LibA/XXX.h>
     //autre includes de libA
     #ifdefine TOTO
             #define TOTO_A
     #else
             #undef TOTO_A
     #undef TOTO
#endif
 
#ifdefine MODE_LIBB
    #ifdefine TOTO_B
          #define TOTO
     #else
          #undef TOTO
    #endif
    #include<LibB/XXX.h> 
    // autres includes de libB
     #ifdefine TOTO
             #define TOTO_B
     #else
             #undef TOTO_B
    #undef TOTO
#endif

Par contre ça va nécessiter de gros copier/collé.

01/10/2012, 11h03
cob59

Encore une raison d'utiliser #pragma once au lieu de ces macros encombrantes :)
01/10/2012, 11h04
Neckara

Citation:

Envoyé par cob59

Encore une raison d'utiliser #pragma once au lieu de ces macros encombrantes :)

Mais #pragma once n'est pas standard et accepté par tous les compilateur non?
01/10/2012, 11h14
Bousk

Il est accepté par les principaux amha : http://en.wikipedia.org/wiki/Pragma_once#portability
01/10/2012, 12h13
Neckara

Citation:

Envoyé par Bousk

Il est accepté par les principaux amha : http://en.wikipedia.org/wiki/Pragma_once#portability

Donc à ne pas utiliser si on veut faire du code portable ou à utiliser en complément d'une autre méthode.
Sinon selon ton lien, pragma once aura un défaut avec une histoire de reconnaissance de symbole? Donc il ne serait pas toujours fiable ?
01/10/2012, 14h10
cob59

Tout dépend de ce qu'on considère comme du code portable.
On pourrait dire que Boost non plus n'est pas portable, puisqu'il existe des plateformes où il ne compile pas.

#pragma once est géré par un nombre raisonnable de plateformes, aussi on peut espérer qu'il soit prochainement intégré à la norme du C++ (ce ne serait pas le 1er #pragma intégré à la norme d'ailleurs).

Quand aux problèmes de symlink/hardlink, je n'ai jamais eu ce problème, mais la responsabilité semble plutôt porter sur l'implémentation défectueuse du compilo, non ?
01/10/2012, 15h43
JolyLoic

Citation:

Envoyé par cob59

#pragma once est géré par un nombre raisonnable de plateformes, aussi on peut espérer qu'il soit prochainement intégré à la norme du C++ (ce ne serait pas le 1er #pragma intégré à la norme d'ailleurs).

Il a déjà été longuement discuté en comité de normalisation. Le problème est que pour le définir, il faut définir la notion de "même fichier", et que cette notion est complexe à définir (d'ailleurs, il risque d'y avoir le même problème quand on commencera à parler des modules)
01/10/2012, 16h34
Jean-Marc.Bourguet

Citation:

#pragma once est géré par un nombre raisonnable de plateformes, aussi on peut espérer qu'il soit prochainement intégré à la norme du C++ (ce ne serait pas le 1er #pragma intégré à la norme d'ailleurs).

Tu as des nouvelles? J'ai vu des opinions en l'air, mais ne me souviens pas de la moindre proposition formelle et quand on voit le nombre de choses formellement proposes qui n'aboutissent pas, je crois tes espoirs infondes.

Citation:

Quand aux problèmes de symlink/hardlink, je n'ai jamais eu ce problème, mais la responsabilité semble plutôt porter sur l'implémentation défectueuse du compilo, non ?

Et c'est quoi le comportement voulu? (IBM inclus plusieurs fois, gcc pas). Si l'objectif est d'avoir le meme comportement que les gardes, gcc a raison. Mais pretendre que deux fichiers hardlinke sont les memes, c'est difficilement justifiable.

Si je regarde les 3 compilateurs que nous utilisons (Sun, IBM, GCC), un n'a pas pragma once et les deux autres ont un comportement different pour un cas present chez nous (les liens symboliques). La portabilite, c'est un peu plus que d'avoir une plateforme ou les differents compilateurs ont converge vers un comportement, surtout quand, a ce que je sais, cette plateforme ne fournit pas les fonctionnalités qui rendent la feature difficile a definir et qu'elle a un acteur dominant forcant en pratique les autres a suivre sa definition.