Discussion :

[lkr22]

Bonjour,

J'ai une application en C++ (qui n'a pas été codé par moi), elle est consitutée de nombreux projets dans une solution.

A l'intérieur de cette solution, il y a 3 éléments qui peuvent nous interésser pour mon problème.

J'ai mon projet .exe , une dll 1 et une dll 2.

La dll 1 transmet des informations au projet .exe qui sont ensuite transmises du .exe à la dll2.

J'aimerai que la dll2 envoie la valeur d'une variable à la dll1. J'ai suivi les protocoles classiques (dllexport ...) aucune erreur de compilation cependant que je lance le debugger le programme plante, je pense que cela est du au fait que j'utilise des informations de la dll1 donc je ne peux pas lui envoyé malgré que j’utilise ces informations en passant par le projet .exe, je ne sais pas si ce que je souhaite faire est faisable. Je transmet un petit schéma ci-dessous pour clarifier mon explication



Vu que je ne maitrise pas vraiment cet aspect de la programmation, c'est possible que la réponse soit simple

[LittleWhite]

Bonjour,

Quels sont les informations qui doivent être échangées et pourquoi ne pas les mettre dans un fichier ou tout autre méthode de communication
Mais je m'emballe peut être, car au final, vous avez les DLL, donc les .h à utiliser pour accéder à la DLL. Donc, pour vous débloquer, je pense que vous devriez utiliser le débogueur.

[Médinoc]

Une DLL peut tout simplement en référencer une autre, appeler ses fonctions, etc.
(par contre, en cas de dépendance circulaire c'est plus compliqué)

[Bousk]

Pourquoi l'exe ne pourrait pas transférer les données de Dll2 à Dll1 alors qu'il le fait dans l'autre sens ?
Sinon tu pourrais aussi enregistrer une callback ou un foncteur.

[lkr22]

J'ai trouvé une autre solution !

Je sais qu'une DLL peut en référencer une autre mais ça ne va que dans un seul sens, si DLL1 dépend de DLL2 , DLL2 ne peut pas dépendre de DLL1 cela crée une dépendance circulaire chez moi et donc le programme plante, j'ai trouvé une autre solution en dupliquant les méthodes que je voulais utiliser dans l'autre DLL mais je pensais que ce que je demandais été possible apparement c'est plus compliqué

[Bousk]

Tout est possible, parfois c'est plus ou moins compliqué.
Après faudrait une demande claire et précise... ce ne sont pas les moyens qui manquent, mais tu sembles ignorer nos réponses... et continuer à forcer une architecture au moins bancale.

[lkr22]

Je n'ai pas ignoré ton message, en fait je crois que les flèches sont dans le mauvais sens.

L'exe dépend de la dll 1 , la dll 2 dépend de l'exe et de la dll1, il est apparemment impossible ou très compliqué de faire dépendre la dll 2 de dll 1 , cela crée une dépendance circulaire.

De plus l'attribut que je veux transmettre à la dll 1, je veux la transmettre dans une méthode qui est utiliser par l'exe ainsi que la dll 2 ailleurs dans le projet. Donc ca fait une sorte de boucle infini, c'est pour cela que le problème est compliqué surtout vu mon niveau.

En gros si j'ai bien compris la dll 1 a besoin de la dll 2 et de l'exe pour "démarrer" mais si la dll 1 a besoin de la dll 2 pour démarrer, ca ne peut pas fonctionner, ils vont "s'attendre mutuellement" selon moi c'est plus ou moins cela le problème.

Du coup j'ai récuperer le code de la méthode de ma dll 1 et j'en ai crée une nouvelle méthode dans ma dll 2 qui fait plus ou moins la même chose, pourquoi qualifies-tu cela de bancale ?

[LittleWhite]

Bonjour,

Pourquoi ne pas faire une DLL3, qui contient le code commun entre DLL1 et DLL2. Du coup, la DLL3 est une dépendance pour les deux autres DLL.

Aussi, depuis le début, je me demande : parlons nous bien de DLL (une bibliothèque, contenant un ensemble de méthodes et exposés par un .h) ou juste de couple de fichiers .cpp/.h ?
Note : c'est toujours bancal (une mauvaise idée) de dupliquer du code.

[lkr22]

Oui nous parlons bien de DLL, je travaille sur le code d'un logiciel Open Source. Une des dll déjà présente possédait une méthode que je souhaitais modifier mais la modifier directement à sa base va modifier son fonctionnement la ou la méthode était déjà utiliser pour d'autres applications d'ou la "duplication" du code afin de ne pas perturber les autres fonctionnalités du logiciel.

J'avais pensé et essayé l'idée de créer une nouvelle DLL comme tu me le suggères mais la raison ci-dessus a fait que j'ai préféré "dupliquer" et modifier la méthode.

Je comprends pourquoi c'est bancale, l'idée de la 3e DLL contenant la méthode commune est plus intéressante lorsque l'on souhaite utiliser une méthode identique, ce n'est pas mon cas donc je ne pense que je n'ai pas d'autres choix

[bacelar]

Comme je l'avais déjà signalé, et mes VDD aussi, vous vous fourvoyez sur une mauvaise solution.

si DLL1 dépend de DLL2 , DLL2 ne peut pas dépendre de DLL1 cela crée une dépendance circulaire chez moi et donc le programme plante,

C'est malheureusement tout à fait possible.
Le plantage n'est pas dû à une impossibilité "technique" mais au fait de gérer cela correctement est extrêmement complexe (et le jeu n'a vaut que rarement la chandelle).

j'ai trouvé une autre solution en dupliquant les méthodes

Ça sent vraiment pas bon.

la dll 2 dépend de l'exe et de la dll1

Une Dll peut difficilement dépendre de l'exe qui la charge.

il est apparemment impossible ou très compliqué de faire dépendre la dll 2 de dll 1

Bin non:
|->DLL1->DD2
EXE
|->DD2

je veux la transmettre dans une méthode qui est utiliser par l'exe ainsi que la dll 2 ailleurs dans le projet.

Commencez par voir les mécanismes d'extensibilité de l'architecture de votre projet.
Là, c'est de la rustine.
Prenez le temps d'analyser le problème et de le formuler à l'écris, ici par exemple.
Si vous n'arrivez pas à nous l'expliquer c'est très probablement que vous n'avez pas assez analysé le problème.

En gros si j'ai bien compris la dll 1 a besoin de la dll 2 et de l'exe pour "démarrer"

Non, la Dll 1 demande à ce que la dll2 soit chargée dans l'exécutable, l'ordre d'appel des DllMain des Dll n'est pas déterministe, et le contexte d'exécution de ces dernières est très spéciales.

Donc ca fait une sorte de boucle infini,

Il n'y aucune boucle, sauf celle du loader de l'OS qui lance les DllMain des Dll dans un ordre arbitraire, après avoir chargé TOUTES les dlls liées "statiquement" (et transitivement EXE dépend statiquement de DLL1 et DLL1 dépend statiquement de DLL2 alors EXE dépend de DLL2 (indirectement)) à l'exécutable.

En gros si j'ai bien compris la dll 1 a besoin de la dll 2 et de l'exe pour "démarrer" mais si la dll 1 a besoin de la dll 2 pour démarrer, ca ne peut pas fonctionner, ils vont "s'attendre mutuellement" selon moi c'est plus ou moins cela le problème.

Absolument pas.
Le loader regarde l'en-tête de l'exe, voit la liste des dll liés statiquement à l'exécutable, charge les Dll, regarde dans l'en-tête de chaque Dll la liste des dll liés statiquement à dite dll, s'il manque des dll dont dépend d'autres Dll déjà chargées, il les charges, etc... jusqu'à ce qu'il n'existe plus de Dll manquantes (le nom du fichier de la Dll sert d'identifiant de la Dll, et c'est là un gros problème (contrairement à .NET qui utilise des signatures en plus des noms)).
Puis, il lance les DllMain de chaque Dll dans un ordre arbitraire.

Du coup j'ai récuperer le code de la méthode de ma dll 1 et j'en ai crée une nouvelle méthode dans ma dll 2 qui fait plus ou moins la même chose, pourquoi qualifies-tu cela de bancale ?

Commencez par voir les mécanismes d'extensibilité de l'architecture de votre projet. (BIS)

Oui nous parlons bien de DLL, je travaille sur le code d'un logiciel Open Source. Une des dll déjà présente possédait une méthode que je souhaitais modifier mais la modifier directement à sa base va modifier son fonctionnement la ou la méthode était déjà utiliser pour d'autres applications d'ou la "duplication" du code afin de ne pas perturber les autres fonctionnalités du logiciel.

C'est pas comme ça que fonctionne un projet OpenSource, normalement.
Vous voulez étendre une méthode, vous la modifiée et lors du PushRequest, les tests unitaires vérifieront que vous n'avez fait qu'étendre la méthode.
Et pensez à ajouter les tests unitaires pour valider vos extensions.

ce n'est pas mon cas donc je ne pense que je n'ai pas d'autres choix

Pensez encore.

Vous n'avez pas donné assez de détails et vous avez fait de telles erreurs de raisonnement qu'on n'est sûr que vous n'avez pas évaluer correctement les possibilités, même les plus évidentes.

[lkr22]

Ça sent vraiment pas bon.

Pourquoi ? Je comprends que ca ne sente pas bon dans le cas d'utiliser une méthode identique, il est inutile de la dupliquer, cependant si il est nécessaire de la modifier je ne comprends pas mes autres options, sachant que c'est un logiciel open source, je ne peux pas me permettre de modifier des méthodes d'une dll qui sert a d'autres fonctionnalités, et si je souhaite utiliser cette méthode sous forme dérivé je n'ai pas le droit de la copier et de la modifier selon mes objectifs ?

Une Dll peut difficilement dépendre de l'exe qui la charge.

Mauvaise expression de ma part

Bin non:
|->DLL1->DD2
EXE
|->DD2

DLL2 dépend de DLL1 , DLL1 peut dépendre de DLL2 apparement selon vos informations mais dans mon cas c'est trop complexe pour l'objectif souhaité (recuperer un entier), de plus cette question ne se pose plus car je souhaite modifier la méthode.

Commencez par voir les mécanismes d'extensibilité de l'architecture de votre projet.
Là, c'est de la rustine.
Prenez le temps d'analyser le problème et de le formuler à l'écris, ici par exemple.
Si vous n'arrivez pas à nous l'expliquer c'est très probablement que vous n'avez pas assez analysé le problème.

Je ne comprends pas ce que vous entendez par architecture de votre projet.

Je recapitule j'ai le code d'un logiciel open source, je dois y ajouter une fonctionnalité, pour la réalisation d'une partie de mon programme une méthode existe deja dans le logiciel mais elle ne colle pas exactement a mon objectif, je dois donc la modifier. Donc je me sers de la méthode de base (présente dans le code source) afin de la modifier selon mes objectifs, mais "ca ne sent pas bon". Vous etes plusieurs a le dire donc ca semble legitime mais je n'ai a priori pas d'autres choix vu mon objectif, je dois donc abandonner ce projet ?

A la base je pensais justement reutiliser la méthode en "liant" les DLL pour pouvoir appeller cette méthode dans ma dll via l'autre dll, ce qui m'a causé un problème mais problème revolu car la méthode ne convient pas a mon objectif, elle doit etre modifiée.

C'est pas comme ça que fonctionne un projet OpenSource, normalement.
Vous voulez étendre une méthode, vous la modifiée et lors du PushRequest, les tests unitaires vérifieront que vous n'avez fait qu'étendre la méthode.
Et pensez à ajouter les tests unitaires pour valider vos extensions.

Est-ce obligatoire de partager mon ajout ? L'utilisation en local uniquement n'est pas autorisé ? Si elle l'est la question ne se pose plus.

Pensez encore.

Il se peut en effet qu'il y ai d'autres solutions, mais mes compétences et ma pensée sont limitées à la technique que je souhaite utilisé pour le moment.

Remarque: Meme si lier mes DLL n'est plus d'actualité, je signal que lorsque je voulais créer une dépendance entre la DLL1 et la DLL2 aucun soucis ensuite je voulais en créer une entre la DLL2 et la DLL1 la case était grisé car on aurait "une dépendance circulaire" ce qui à mon sens et je peux me tromper s'explique par le fait que l'attribut de la DLL2 que je souhaitais transmettre à la DLL1 avait pour but d'etre utiliser dans une méthode de la DLL1 que j'utilisais deja dans ma DLL2, du coup l'exe pour charger la DLL1 a besoin que la DLL2 soit chargé et vice versa du coup ca tourne en rond (et les dll sont elles toujours liées statiquement ? Pour moi elles l'étaient dynamiquement d'ou mon "ancien problème")

Merci des réponses en tout cas j'apprends des choses.

[bacelar]

Pourquoi ? Je comprends que ca ne sente pas bon dans le cas d'utiliser une méthode identique, il est inutile de la dupliquer, cependant si il est nécessaire de la modifier je ne comprends pas mes autres options

Exemple:

Code :

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

int add(int a, int b) {return a + b;}

Pour implémenter "add(int, int, int)", on ne va pas faire un copier-coller la la fonction "add".

int add(int a, int b, int c) { return add(a,b) + c;}

Ainsi, en cas d'optimisation de "add(int,int)" ou correction de bug, "add(int, int, int)" en bénéficiera automatiquement.

Exemple totalement arbitraire et artificiel, mais comme le dit l'adage, il n'y a que du mauvais code qui se copie-colle.

sachant que c'est un logiciel open source,

Je ne vois pas ce que cela change au "débat", sauf que vous pourriez nous indiquer le projet et la fonction pour avoir le cas concret du "problème".

je ne peux pas me permettre de modifier des méthodes d'une dll qui sert a d'autres fonctionnalités,

Et pourquoi ? si vous étendez/amélioré la dite fonction ? Cf. mes remarques sur les tests unitaires.

et si je souhaite utiliser cette méthode sous forme dérivé je n'ai pas le droit de la copier et de la modifier selon mes objectifs ?

Si les extensions ne se servent que pour vous, vous devriez utiliser les fonctions Open source pour implémenter vos fonctionnalités, pour bénéficier automatiquement des améliorations et correction de bugs de celles-ci.

DLL2 dépend de DLL1 , DLL1 peut dépendre de DLL2 apparement selon vos informations mais dans mon cas c'est trop complexe pour l'objectif souhaité (recuperer un entier), de plus cette question ne se pose plus car je souhaite modifier la méthode

La mise en forme du post a complétement écrasé mon "dessin".

|
EXE
|->DLL1->DD2
|->DD2

L'exe dépend de DLL1 et de DLL2, DLL1 dépend de DLL2.

de plus cette question ne se pose plus car je souhaite modifier la méthode.

Vous vous contredisez. Vous ne voulez pas toucher au code origine, vous le copié dans votre projet, mais vous souhaitez "modifier" la fonction ?
C'est pas cohérent. Soit vous la modifié pour la corrigé ou l'étendre soit vous vous vous en servez comme base et vous n'avez pas à la modifier.


Le plus simple et concret, c'est de nous montrer la fonction que vous voulez "récupérer" et l'action que vous voulez faire, pour vous indiquer une marche à suivre plus pérenne que celles que vous semblez vouloir prendre.

Je ne comprends pas ce que vous entendez par architecture de votre projet.

Un projet a toujours une architecture, qui permet plus ou moins simplement d'être maintenu et étendu.
Si cela ne vous dit rien, c'est que vous n'avez pas assez analysé le projet de base.

je dois y ajouter une fonctionnalité,

Quel est la portée de cet ajout ?
patch ? extension "technique" ? extension "fonctionnelle" ? etc...

pour la réalisation d'une partie de mon programme une méthode existe deja dans le logiciel mais elle ne colle pas exactement a mon objectif

Soyez plus concret, SVP ?

je dois donc la modifier.

NOPE, on n'ai jamais obligé de modifier du code existant sans bug connu.

Donc je me sers de la méthode de base (présente dans le code source) afin de la modifier selon mes objectifs, mais "ca ne sent pas bon".

Le plus pérenne, n'est pas de modifier la méthode, mais de vous en servir pour implémenter la vôtre.

je n'ai a priori pas d'autres choix vu mon objectif, je dois donc abandonner ce projet ?

Montrez la méthode initiale et indiquez concrètement vos objectifs.

Vous faites une fixette sur les Dll, mais ce n'est qu'un moyen de distribution de code binaire. Il y a tellement d'autres fonctionnalités d'extension que je ne comprends pas votre fétichisme de la Dll.
Le mode de distribution du code, c'est un détail à faire après analyse et implémentation de l'extension.

Est-ce obligatoire de partager mon ajout ? L'utilisation en local uniquement n'est pas autorisé ? Si elle l'est la question ne se pose plus.

C'est fonction de la licence du projet.
Open Source, cela ne veut pas dire libre de droit, loin de là.

lorsque je voulais créer une dépendance entre la DLL1 et la DLL2 aucun soucis

Soyez plus précis, SVP. Il y a toujours un sens dans la dépendance.

ensuite je voulais en créer une entre la DLL2 et la DLL1 la case était grisé car on aurait "une dépendance circulaire"

Comme c'est un cas d'usage quasi-toujours foireux, votre IDE vous empêche de vous pendre avec ces conneries.
Quel cas d'usage peut-il être légitime de distribution de 2 dll cycliquement dépendante ?
Moins j'en vois aucun, sauf une conception faite avec les pieds.
Si Dll1 a besoin de Dll2 et Dll2 a besoin de Dll1, il ny a pas à tortiller du cu*, vous fusionnez les deux Dll.

le fait que l'attribut de la DLL2

De quel "attribut" parlez-vous ?

que je souhaitais transmettre à la DLL1

On ne transmet rien à une Dll, on ne fait qu'appeler des fonctions ou lire/écrire des champs statiques (et c'est bien cracra dans ce cas).

avait pour but d'etre utiliser dans une méthode de la DLL1 que j'utilisais deja dans ma DLL2

C'est donc une fonction de DLL2 qui dépend d'une fonction de DLL1, donc c'est DLL2 qui dépend de DLL1 (en espérant qu'il n'y pas de lien d'en l'autre sens => fusion des DLL pour cacher ce bordel au reste des projets qui n'ont pas à connaitre ce merdier).

du coup l'exe pour charger la DLL1 a besoin que la DLL2 soit chargé et vice versa du coup ca tourne en rond

Vous n'avez pas lu attentivement ma réponse, il n'y aura jamais de cycle car le loader fait le travail en plusieurs passes.

et les dll sont elles toujours liées statiquement ?

La majorité du temps. Sinon, c'est le DelaiLoading ou le chargement à la main, avec "LoadLibrary".

Pour moi elles l'étaient dynamiquement d'ou mon "ancien problème"

Cela ne change rien, que le chargement soit statique ou dynamique, le Loader fait son taf et "gère" les cycles (qui ne devraient JAMAIS exister).

[Médinoc]

Il est possible que ce qui te manque ici, ce soit une couche intermédiaire pour faire une "inversion de dépendance"
Exemple simple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
//DLL1
class MonObjet
{
public:
	void AfficheToi() const { std::cout << "toto" << std::endl; }
	static void FaireDesTrucs()
	{
		std::vector<MonObjet> lst { /*...*/ };
		Traitements::TraiterListe(lst);
	}
};

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//DLL2
class Traitements
{
public:
	static void TraiterListe(std::vector<MonObjet> const &lst)
	{
		for(auto it=lst.begin() ; it!=lst.end() ; ++it)
		{
			//...
			it->AfficheToi();
			//...
		}
	}
}

Le code ci-dessus met bien en évidence une dépendance circulaire, mais elle peut être évitée ainsi:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
//DLL1
class MonObjet : public IAffichable
{
public:
	void AfficheToi() const { std::cout << "toto" << std::endl; }
	static void FaireDesTrucs()
	{
		std::vector<MonObjet> lst /*{ ... }*/;
		std::vector<std::reference_wrapper<IAffichable const>> lst2(lst.begin(), lst.end());
		Traitements::TraiterListe(lst2);
	}
};

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
19
20
//DLL2
class IAffichable
{
public:
	virtual void AfficheToi() const = 0;
};
 
class Traitements
{
public:
	static void TraiterListe(std::vector<std::reference_wrapper<IAffichable const>> const &lst)
	{
		for (auto it = lst.begin(); it != lst.end(); ++it)
		{
			//...
			it->get().AfficheToi();
			//...
		}
	}
};

Et juste comme ça, DLL2 ne dépend plus de DLL1! L'ajout de l'interface dans DLL2 a permis d'inverser la dépendance.

Note: Il faut un compilo plus récent que Visual 2010, qui ne supporte apparemment pas les reference_wrapper de classes abstraites. Visual 2017 accepte ce code sans problème.