conditions dans les .h

Bonjour,

Je me demandais juste s'il était possible (et si oui, comment) de connaître le nom du fichier à partir duquel un .h se fait inclure, afin d'éviter ou non certaines déclarations dans le .h (des extern const, en l'occurence).

J'ai bien pensé à tester la "variable" __FILE__, mais cela ne semble pas convenir. Des idées ?

Si tu respecte une certaines uniformité dans les #declare pour savoir si un fichier .h est inclut, tu peux aisément savoir si tel ou tel fichier est inclut ou non :

Dans chaque .h :

#ifndef NOMFICHIER_H
#define NOMFICHIER_H

// le reste de ton fichier.h

// et à la fin :
#endif

Et ensuite, pour faire ton test :

#ifdef NOMFICHIER_H
// tu sais que le NOMFICHIER.h est inclut dans ce fichier !

Oui çà je le gère déjà pour éviter les inclusions multiples, mais ce que je voudrais c'est connaitre le fichier qui a fait le #include... En fait, j'aurais besoin du test dans le .h, prenons un exemple çà sera plus clair ;-)

fichier toto.c :
#include "toto.h"
int toto = 2;

fichier toto.h :
#ifndef __TOTO_H__
  #define __TOTO_H__
  extern const int toto;
#endif

Voilà... Ici je sais que çà ne sert à rien, mais toto est en fait initialisé par une fonction dans toto.c, et doit être constant dans tous les autres modules qui incluent toto.h (je sais pas si je suis très clair ?)

Ah ok, non ca je ne vois pas comment faire, désolé !

Je ne vois pas vraiment l'interet de tout ca ou alors je ne dois pas comprendre...

pour que toto soit constante dans tous les autres modules, il faut qu'elle soit constante aussi dans le fichier .c ou elle est declaré...
en fait quand tu mets une variable de type extern, il faut que le type soit le meme que la variable qu'elle designe...
Bob...

"La chance accorde ses faveur aux esprits avertis..."

Nebula> Si dans toto.c tu crée un défine exprès pour ca:

#define C_EST_TOTO_C_QUI_INCLUT
#include "toto.h"
#undef C_EST_TOTO_C_QUI_INCLUT
int toto=2

dans toto.h tu pourra savoir que c'est toto.c qui a inclus ce fichier

LordBob > de même type, pas forcément avec le même accès... on peut très bien avoir une variable modifiable dans un module, que les autres ne peuvent que lire.

vecchio56 > oui c'est ce que je faisais au début, mais je me demandais si on pouvait éviter cette méthode... tant pis, je resterais avec cette solution.