Discussion :

[Kromagg]

Bonjour à tous

Présentation du contexte : disons que j'aimerai créer une application, par exemple un moteur de rendu de terrain en 3D (avec Visual C++ et uniquement sous Windows) qui serait représenté par une dll. Comment je peux savoir si je dois ou pas exporter une classe dans cette dll ? Quel(s) critère(s) dois-je prendre en compte ? Y'a-t-il des règles ?

Merci d'avance
Kromagg

[koala01]

Salut,

Le critère le plus important sera déjà le contenu de la classe en question...

Si elle n'utilise que des type POD (c'est à dire des types primitifs ou des structures composées de types primitif, sans fonction membre), tu peux l'exporter sans trop de problèmes (mais j'hésite quand même à rajouter comme condition que la structure soit elle même de type POD )

Dans tous les autres cas, si tu prend la décision d'exporter une de tes classes dans une dll, il faudra que l'application qui utilise cette classe soit compilée avec la même version de compilateur et les même options de compilation que la dll, ce qui restreint singulièrement l'utilisation qui pourrait être faite de ta dll.

Maintenant, si la dll en question fait partie intégrante du projet de l'application (qu'il ne s'agit que d'un "plugin" de l'application), que le tout ne sera jamais livré que de concert et que l'application et la dll sont destinées à être systématiquement compilées ensemble (ou peut s'en faut), tu ne souffrira pas de cette limite

Si tu n'est pas dans le cadre d'une structure de type POD, il s'agira donc d'évaluer s'il est opportun ou non de placer cette limite quant à l'utilisation de la dll.

Et, bien sur, tu dois veiller à ce que la dll n'exporte en tout état de cause que ce qui est nécessaire à son travail de manière générale:

S'il y a une classe qui ne sert qu'à "usage interne" (comprend: que l'utilisateur de la dll peut même ignorer que la classe existe, parce que sa gestion est intégralement prise en charge de manière transparente par d'autres), il n'y a aucune raison de l'exporter

Il y a peut être d'autres facéties à prendre en compte, mais ce sont celles qui me viennent de prime abord à l'esprit

[nicroman]

Une méthode comme une autre si tu n'as pas envie de t'aventurer dans l'architecture complete, c'est de ne rien exporter... et voir au fur et à mesure ce qu'il manque (le compilo va te le dire si un truc doit être exporté) !
En général un plug-in n'exporte jamais rien, sauf un point d'entrée et/ou une variable statique...

[3DArchi]

Bonjour,
Je rajouterais qu'in fine les classes que tu exportes devraient n'exposer que des services attendus par ta bibliothèques et surtout pas des détails d'implémentation. Ca peut vouloir dire faire des choses comme des classes d'interfaces, l'utilisation du pimpl idiom, etc.
L'idée de nicoman est assez intéressante si tu ne vois pas trop où est la frontière entre ce que tu dois exporter ou non : tu fais ton moteur et ensuite tu créés une première application. Au fur et à mesure que tu fais ton application, tu regardes ce qu'il te manque. Il faut penser à ce qu'il te manque en terme de fonctionnalités et non par rapport à ce que tu as impémentés. Ca peut coïncider ou pas : au quel cas il faut penser à l'interface qui encapsule le service attendus et fait le pont avec ton implémentation.

[Kromagg]

Merci pour vos conseils
Je vais y aller à taton comme suggéré en important seulement au fur et à mesure.
En fait je pensais découper le moteur en deux parties distinctes :
- la partie générale qui concerne le moteur en lui même, les classes de bases, les outils et le rendu.
- la partie plugins ou je vais développer chaque technique de rendu de terrain dans une dll différente.

Merci encore
Kromagg