Macro conditionelle? Import/Export de symboles.

Le titre est un peu abstrait mais comme je ne suis pas spécialiste des macro je ne suis pas sur de comment procéder.

Je voudrais savoir si il y a un moyen d'écrire une fonction macro prenant un paramettre qui sera utilisé pour générer un nom de macro et définir la valeur d'une autre définition macro.

Quelque chose qui ressemblerait à ça (sauf que ce code ci n'a pas le sens que je veux):

Code:

---

1 2 3 4 5 6

#define GENERATE_MODULE_API( module_api_macro_name ) \ #ifdef module_api_macro_name##_EXPORTS \ #define module_api_macro_name##_API My_DllExport \ #else \ #define module_api_macro_name##_API My_DllImport \ #endif

---

Je ne vois pas de façons de le faire.

Ce que j'aimerai faire c'est que chacun de mes projets DLL/SO puisse automatiquement générer une macro MON_MODULE_API qui serait l'équivalent de ceci:

Code:

---

1 2 3 4 5 6 7

#ifdef MONPROJET_SYSTEM_EXPORTS #define MONPROJET_SYSTEM_API My_DllExport #else #define MONPROJET_SYSTEM_API My_DllImport #endif   #endif

---

Actuellement je dois faire un header par projet qui doit contenir ce code ci dessus (avec le nom du projet changé à chaque fois).

Si vous avez une manière de le faire plus générique, je suis preneur.

Salut,
A ma connaissance, tel quel, cela ne marche pas. Le preprocessing se fait en un seule passe.
Une solution : un template de header/une macro de ton IDE, etc... (bref une solution hors langage).

Et, d'ailleurs, c'est assez malheureux. (que ça ne soit pas possible)
Sinon, ça permettrait moultes simplifications !

Ok je voulais juste être sur parceque je me souviens être arrivé à la même conclusion auparavant, mais peut être que des outils dans Boost ou autre auraient pu aider...

Bon ben c'est reparti pour un header par projet :cry:

'limite, il est peut-être possible de configurer le compilateur, en lançant deux phases de préprocessing ? p.ex. lancer le préprocesseur sur la source, puis lancer la compilation totale sur la source ainsi générée ... ?

Citation:

---

Envoyé par Ekleog

'limite, il est peut-être possible de configurer le compilateur, en lançant deux phases de préprocessing ? p.ex. lancer le préprocesseur sur la source, puis lancer la compilation totale sur la source ainsi générée ... ?

---

J'ai du bosser avec un outil qui faisait ça. Conclusion => à bannir car c'est très pénible (problème principal #idef/define des headers virés à la première phase puis injection par besoin de nouvel include lors de la seconde passe)

Ah.

La solution est peut-être alors de préposer les #define qui sont présents à la fin du premier preprocessing au début du fichier préprocessé.
Je m'explique, avec un exemple :

Code:

---

1 2 3 4 5

// include_once.h #ifndef include_once #define include_once // ...1 #endif

---

Le fichier de départ :

Code:

---

1 2 3 4

#define INCL #include <include_once.h> #include <include_once.h> INCL // ...2

---

Premier préprocessing :

Code:

---

1 2 3

// ...1 #include <include_once.h> // ...2

---

Préposage des defines présents à la fin :

Code:

---

1 2 3 4 5

#define include_once #define INCL #include <include_once.h> // ...1 #include <include_once.h> // ...2

---

Second préprocessing :

Code:

---

1 2	// ...1 // ...2

---

Mais, bon, ça nécessite quasiment le développement d'un préprocesseur personnel (simplifié par boost.wave, quand même).

Une autre solution serait de ne pas étendre les include à la seconde phase, mais ça réduirait de beaucoup l'utilité ...

Ou alors il faudrait les Modules. :aie:

(je sens que ça va devenir un running gag depuis les conférences Going Native).


Bon plus sérieusement, je ne vois aucune manière "simple" de le faire sans avoir à écrire ou générer un fichier header spécifique à chaque projet.

Je n'ai pas encore eu le temps d'écouter toutes les Going Native, tu peux préciser ?

Citation:

---

Envoyé par Ekleog

Je nai pas encore eu le temps d'écouter toutes les Going Native, tu peux préciser ?

---

En gros, les stars du C++/du commité disaient que le problème avec les Modules c'est qu'on ne comprends pas bien ce qu'ils resolvent : la plupart des gens y voient la solution à leurs problèmes spécifiques, même si ils sont contradictoires entre les différentes personnes. Du coup la blague c'est que les modules c'est une de ces features virtuellement miracle.

Et c'est aussi pour ça qu'il y a peu de chances pour qu'on les ai dans moins de 5 ans... sauf si l'implémentation (dispo dans CLang) prouve l'utilité, aide à accélérer le mouvement (ou l'inverse).