Discussion :

[awawawa]

Bonjour tout le monde,

Désolé : je suis entrain de bombarder le forum en ce moment, mais j'essaye de comprendre les Dlls and co en ce moment et n'étant pas informaticien de formation, je peux vous dire que certains passages sont relativement cotons.

Ici c'est plus une question de méthode qu'un réel problème.

Bon sur internet on trouve plein d'explications sur la conception de classe, l’héritage, les espaces nom and co...

Sur internet aussi on trouve aussi plein de tutoriels sur comment concevoir sa première Dll (que ce soit une classe ou une famille de fonctions) : ça je pense l'avoir compris, je défini DLLLAFAMILLE_EXPORTS dans mon préprocesseur et puis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#pragma once
#include <iostream>
 
#ifdef DLLLAFAMILLE_EXPORTS
#define StrategyImportExport __declspec(dllexport)
#else
#define StrategyImportExport __declspec(dllimport)
#endif
 
 
namespace NameSpaceA {
	class StrategyImportExport Mere
	{
	public:
		Mere();
		~Mere();
	};
}

Là, sous ms visual, il me crée un .lib et un .dll et je peux utiliser par la suite (avec le .h) dans un nouveau projet où évidemment je ne déclarerai pas DLLLAFAMILLE_EXPORTS dans les préprocessus.

Jusqu'à là j'ai bon?


Sur internet ce que l'on trouve moins, c'est comment créer proprement un DLL à partir d'une famille de n classes (qui dépendent les unes des autres). Alors supposons que j'ai crée des classes qui obéissent à un diagramme suivant (le plus exhaustif qui soit) :





D'après vous, que vaut-il mieux faire :

• Créer une macro globale dans header le plus en amont : du coup ici dans classeMere et un autre dans classeTierse (est-ce qu'elle peu dans ce cas avoir le même nom) + création d'un proprocessus unique exporter chacune des classes que je souhaite en mettant un StrategyImportExport devant le nom de la classe?
• Créer un macro par classe (mais dont le nom change d'une classe à l'autre), associer à chacune d'une maccro un nom défini ou pas dans le pré-processus (en fonction que l'on souhaite l'exporter ou pas).
• Ou sinon une autre solution? Vous feriez quoi?

Merci d'avance pour vos conseils!

[Bousk]

Que tu exportes 1 ou 1M de classes c'est pareil : il faut qu'elle soit dllexport à la compilation pour être exportée et dllimport pour être importée.
Partant de là, la logique et le bon sens veut qu'on utilise la même macro pour toutes les classes.
Et quand tu crées une lib exportée, il y a généralement des fichiers de configuration qui définissent ce genre de trucs et sont utilisés partout où nécessaire.

[awawawa]

Voilà une réponse simple et concise.

Merci.

[bacelar]

On va commencer par le début : Faire une Dll avec une API C++ (avec des classes) et non C, c'est totalement foireux.
Pour vous servir de votre machin.dll dans un exécutable, il vous faudra utiliser le même compilateur, voir la même version du compilateur et les mêmes options de compilation que ceux qui ont été utilisés pour générer "machin.dll".
C'est dans la pratique, quasi totalement inutilisable.

Après, si vous voulez faire un jouet, c'est vous qui voyez.

Je confirme ce qu'a écrit @Bousk, une seule MACRO fera largement l'affaire.

Après, on peut affiner la stratégie des header pour que la Dll soit plus utilisable (aussi bien avec un API C que C++, pour le coup).

Un header général à la Dll mais "privé", qui contiendra la MACRO et qui sera inclus par tous les headers des classes publiques de l'API.
Un header général publique, "le header de la lib", qui inclura toutes les classes publiques de la lib, formant l'API de la lib.

L'utilisateur n'aura donc cas inclure le header général publique pour avoir accès à toute l'API de la lib et à rien d'autres.

[awawawa]

Et bien Bacelar Merci pour cette info!

Du coup tu me conseilles quoi? Faire des librairies statiques?

[bacelar]

Je me suis un peu embrouillé avec les header privé/public.

On peut s'arranger juste avec un header chapeau public qui définit la MACRO et inclus les classes publiques.
Les header des classes publiques incluant aussi cet header "chapeau".

Les librairies statiques on les mêmes problèmes de portabilité que les librairies dynamiques, mais en plus, même avec une API C.

Mais le mode d'usage n'est pas le même, la librairie n'a pas à changer durant l'exploitation de l'exécutable.

Si tu n'a pas la bonne version de la librairie au moment de la compilation de la librairie, il n'y a qu'à régénérer la librairie statique et puis c'est tout, mais si c'est pour avoir à distribuer la librairie sans les sources, ça va coincer.