Discussion :

[Ange_blond]

Hello,

suite à mon post sur les dll et les soucis de compil et d'export, voilà qu'un autre soucis, ou plutot quelque chose de plus profond me perturbe :

J'ai donc un projet, conséquent, que je veux découper en dlls. Seulement certaines partie du code, disons des ensembles de classes qui communiquent entre elles, pour les externaliser du projet.

Seulement, comme ces classes, une fois externalisés dans un autre projet, étaient malgré tout bien imbriquées dans celui de base et donc les dépendances sont bien là : pour compiler mes dlls, je dois linker avec mon projet de base en lib (ce qui est logique jusque là). J'ai donc mon exe compilé en exe et en lib.

Vient ensuite le point clé : mon exe, lorsqu'il charge ladite dll, charge aussi ses dépendances (celles de la dll), qui sont donc ma lib de base...
Ainsi, mon exe créé une instance des classes de la dll, qui elle meme créé des instances de classes de la lib ... donc au final le code de l'exe est instancié deux fois !

Je pense que le probleme est donc évident ... L'idée de base pour remédier à ça est de faire en sorte que la dll n'ai aucune dépendance pour éviter d'avoir à utiliser mon projet en lib... Mais c'est bcp de boulot !

donc si vous avez des idées... je suis toute ouïe :-)

Merci.

[bacelar]

Je ne vous de différence entre ton problème et la modularisation classique.

Par modularisation, c'est mettre toutes les classes qui se connaissant dans une dll (pas une lib) et fournir à l'extérieur une API simple, sans aucune assertion sur l'appelant de cette API.

Si la conception est bien faîte, il n'y rien à faire que de transférer les .h et les .cpp de ton projet d'exe vers celui ou ceux de(s) dll.

Si cela n'est pas possible, c'est qu'il y un trop fort couplage et il existe un nombre considérable te techniques et de Design Pattern pour découpler des composants.

Le choix doit se faire en fonction du type de couplage à supprimer.

En un mot : DECOUPLE.

[GeMyNy]

Ca ressemble à un problème de dépendances circulaires. Dans ton cas, tu peux peut-être t'en sortir simplement en en créant une nouvelle dll avec la partie de l'Exe qui est utilisée dans ta dll de base ?

[Ange_blond]

Ca ressemble à un problème de dépendances circulaires. Dans ton cas, tu peux peut-être t'en sortir simplement en en créant une nouvelle dll avec la partie de l'Exe qui est utilisée dans ta dll de base ?

Non c'est pas juste ça, c'est un soucis de conception vraisemblablement.

La particularité, est que je veux que les dll (plugins) soient chargés dynamiquement, et donc pas à la compil via le linker. en gros ce ces des dépendances facultatives. Je sais mettre ça en place, mais ça complexifie encore le probleme au final.

[bacelar]

Si l'on parle d'une architecture à plugIn : Tous les plugIns doivent avoir la même API.
Pensez au fait qu'il est très courant d'avoir des plugIn réalisés avec un autre langage que celui utilisé pour l'implémentation du programme hôte.

Donc concevez une API en C (voir en COM pour Windows).

Si vous prenez en compte le caractère polyglotte de l'architecture, les choses que votre plugIn et votre programme se partagent indûment vont se voir comme le nez au milieu de la figure.
Donc il suffira de "Découpler le nez" : le concept d'interface est primordiale dans ces cas là.

Si le problème n'est pas une conception plugable strict mais à une problématique de disponibilité des dll, pensez au DelayLoading sous Windows.

[3DArchi]

Bonjour,
Tu peux offrir une interface abstraite à tes plugins qui sera fourni dynamiquement par l'exécutable à ceux-ci quand il va les solliciter :
// interface.h

Code :

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

1
2
3
4
5
6
 
class IAction
{
public:
   virtual void DoIt()=0;
};

// dll

Code :

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

1
2
3
4
5
6
7
8
 
#include "interface.h"
void faire_exportee(IAction [const]&interface_)
{
   // blablabla
   interface_.DoIt();
   // blablabla
}

// exécutable :

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
 
#include "interface.h"
class CActionConcrete : public IAction
{
public:
   virtual void DoIt()
   {
      // blablabla
   }
};
 
...
CActionConcrete action_concrete;
// faire_exportee peut être obtenue par LoadLibrary/GetProcAdresse si besoin
faire_exportee(action_concrete);

DIP

[Ange_blond]

Bonjour,
Tu peux offrir une interface abstraite à tes plugins qui sera fourni dynamiquement par l'exécutable à ceux-ci quand il va les solliciter

C'est déjà fait :-)

en fait je galere parce que je gere en parallele le cote plugin dynamiquement loadé et export du projet en dll pour éviter les soucis de compil en lib statique ... enfin c'est bordelique pr le moment mais ça va se faire :-)

[bacelar]

Peux-tu être un peu plus concret avec ton problème ?

Par exemple, fournis-nous une arborescence de classes qui illustre ton problème de dépendance entre ton exécutable et tes dlls.

[3DArchi]

En fait, j'ai l'impression que tu as un beau plat de spaghetti. Tu as tout intérêt à commencer par mettre à plat toute ton architecture et retravailler complètement ta conception. Sinon, j'ai peur que tu ne fasses que continuer à tortiller les spaghetti un peu plus.

[Ange_blond]

En effet, c'est assez complexe comme soucis...

La décision a été prise de refaire une partie importante de la conception pour par la suite faciliter considérablement le découpage en plugins.
J'attaque ça aujoud'hui, en theorie il n'y aura pas de soucis... on verra pour la pratique.

Je ne clos pas le topic tant que je n'ai pas la certitude que tout se fera sans soucis, histoire de ne pas ouvrir un nouveau topic pour des questions toujours sur le meme sujet.

Merci.