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.

[awawawa]

mais si c'est pour avoir à distribuer la librairie sans les sources, ça va coincer.

Ben du coup j'ai une collection de fonctions avec un code source (les .cpp) que je n'ai pas forcement envie de faire lire à mon client mais qu'il puisse les utiliser à sa guise si il veut en faire un programme... je fais comment? Je suis un peu perdu

Lorsque j'utilise des librairies pour ma part (genre du qt and co), je n'ai pas spécialement accès au code source... Quelle est la différence?

[bacelar]

genre du qt and co

Pour Qt, vous avez les sources ET vous avez des librairies pré-compilées pour différents compilateurs, ainsi que d'une ribambelle de directives à suivre pour pouvoir vous servir de ces librairies pré-compilées.

Si vous n'avez pas le compilateur qui correspond à l'un des librairies pré-compilées, vous êtes bon pour une recompilation du bousin à partir des sources (ce que beaucoup font pour être sûr la version de Qt, même s'ils ont les librairies pré-compilées pour leur compilateur/version de compilateur/options du projet).

Et vous devez déjà avoir vu que la gestion des versions de Qt (static, pas static, la stdlib avec ou sans thread, etc....), c'est la MORT !!!

Donc, pour Qt, pour travailler sérieusement, il faut être capable de la recompiler soit même et d'être extrêmement rigoureux "l'alignement" des chaines de compilations de l'exécutable et de la version de la librairie qui vous donnez à manger au linker.

Pour les librairies "fermées", en statique (je crois que c'est légion), l'éditeur doit fournir les librairies pré-compilées sur l'ensemble des compilateurs qu'il supporte, donc, généralement pas bésef. (Si ça te convient pas, bon, t'achète pas, ou tu t'alignes sur l'un des compilateurs supportés, point barre).

Pour les Dll "fermées", si c'est une API en C, un simple .h et la Dll ; et des outils de votre chaine de compilation pour générer les .def et autre .lib qui lui sont nécessaire et c'est dans la boite (il y en a même qui ne fournissent même pas le .h, les cochons, c'est à toi d'avoir les outils pour régénérer le .h depuis le .dll (ou tu le crée toi même avec tes petits doigts boudinés)).
Si c'est une API C++, on retombe sur les mêmes problèmes que ceux des librairies statiques (alignement des environnements de génération).