Signification d'un paramètre dans une définition de classe

Bonjour à tous,

Parallèlement à la lecture du cours de Laurent Gomila sur le développement d'un moteur 3D j'ai décidé de parcourir le code d'Ogre3D pour en apprendre encore un peu plus sur la création des moteurs 3D et physiques. Cependant un détail (qui n'a en soi rien à voir avec la programmation objet) me chiffonne :
je ne parviens pas à comprendre le sens de _OgreExport dans

Code:

---

1 2 3 4 5 6 7 8

namespace Ogre { class _OgreExport UneClasse {   ... }

---

Si vous pouviez m'éclairer sur ce détail
Merci
Zouch-K

"_OgreExport" est une astuce pour avoir un seul fichier d'en-tête à la fois pour compiler la dll et pour utiliser la dll.

_OgreExport correspond à un #define qui change en fonction d'une constance de compilation.

Code:

---

1 2 3 4 5 6

#ifdef _OGRE_EXPORT_DLL #define _OgreExport dllspec(dllexport) #else #define _OgreExport dllspec(dllimport) #endif

---

ah ok merci !

par contre, comment ce paramètre est-il qualifié ? j'ai fait plusieurs recherches à ce sujet, mais sans aucune idée du nom qu'il peut avoir c'est pas facile :/

Citation:

---

Envoyé par Zouch-K

par contre, comment ce paramètre est-il qualifié ?/

---

Qu'entends-tu par là ?

En gros, si je veux plus me documenter sur cette "pratique" je dois taper quoi dans google ? ^^
En essayant de trouver de la doc je suis tombé sur "imodel" mais j'ai rien trouvé en faisant des recherches sur ce "mot-clef"
([ame="http://www.codeguru.com/forum/showthread.php?p=1253128"]j'ai trouvé ça ici[/ame])

Salut, et bienvenue sur le forum

Il s'agit en fait de directive préprocesseur et de compilation conditionnelle

Toute ligne commençant par le dièse est une directive adressée au préprocesseur, autrement dit à un outil qui passe avant le compilateur pour appliquer certaines macros.

Les directives #ifndef, #ifdef, #if defined, #else indique au préprocesseur des blocs d'instructions à garder ou à supprimer en fonction de l'(in)existence de certains symboles que l'utilisateur peut définir au moment de la compilation.

ainsi le code suivant

Code:

---

1 2 3 4 5

#ifdef _OGRE_EXPORT_DLL #define _OgreExport dllspec(dllexport) #else #define _OgreExport dllspec(dllimport) #endif

---

sera évalué par le préprocesseur (juste avant la compilation proprement dite) selon une logique proche de

• S'il existe un symbole nommé _OGRE_EXPORT_DLL,
• nous demandons au préprocesseur de remplacer _OgreExport par dllspec(dllexport) chaque fois qu'il le rencontre
• sinon,
• nous demandons au préprocesseur de remplacer _OgreExport par dllspec(dllimport)
• fin de la condition

Oui les directives préprocesseurs je connais y'a pas de soucis.

Le truc qui m'embêtait un peu c'était juste qu'il y ait une macro entre le mot-clé class et le nom de la classe ^^

L'idée ici est que c'est en réalité toute la classe (son nom et son interface publique, du moins) qui sera exportée dans la dll...

Cela te permet, lorsque tu utilise la dll, de pouvoir déclarer une variable du type correspondant et de pouvoir appeler les différentes fonctions publique de cette classe ;)

Il faut cependant signaler que, pour l'instant, l'interface C++ n'est pas standardisée comme peut l'être celle du C. (il est question de faire en sorte que ce soit dans la prochaine norme, me semble-t-il)

Cela implique que, pour bien faire, il est préférable de veiller à compiler la dll et le programme qui l'utilise avec la même version de compilateur.

Par contre, c'est une méthode des plus efficace lorsqu'il s'agit de créer des "plug-in" à un programme et qu'il est question de choisir à l'exécution lesquels utiliser.

Ainsi, la dll utilisant ogre peut se trouver à côté d'une dll utilisant directX ou d'une autre utilisant de préférence OpenGl, et il te devient possible de décider de charger, selon la présence de l'une ou l'autre des technologies, la dll correspondante ;)

Merci beaucoup pour cette explication :D