Discussion :

[simac]

Bonjours! Pour alléger un projet, je sépare mes fonctions dans des DLLs. Seulement, certaines fonctions sont du type:

Code :

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

1
2
3
4
5
6
int foo(int &x)
{
    /*...*/
    bar(x)
    /*...*/
}

où x est une variable de l’exécutable et où bar est utilisé dans l'exécutable et dans d'autres DLLs.
Plusieurs solutions s'offrent alors (liste non-exhaustive):

1. Déclarer la fonction void bar(int &y) dans chaques DLLs et dans l'exe.
   Problème: Ce n'est pas du tout optimisé pour un gain de mémoire.
   
2. Déclarer la fonction void bar(int &y) dans une DLL et l'importer dans toutes les autre.
   Problème: Cela fait beaucoup de dépendances et complique la relecture.
   
3. Déclarer la fonction void bar(int &y) dans l'exe mais l'appeler à partir de la réception d'un message spécifique envoyé à un HWND comme suggéré ici.
   Problème: Pour passer plusieurs paramètres il faut soit utiliser une structure soit un tuple (à choisir je préfère le tuple, ça allège, mais c'est en C++11).
   
4. Déclarer la fonction void bar(int &y) dans l'exe et l'utiliser dans les DLLs.
   Problème: Je ne sais absolument pas si c'est possible.

Si vous avez déjà été confrontés à cette situation, ou si vous avez une idée, pouvez-vous me faire part de votre méthode?

Merci,

Simac

[dragonjoker59]

Salut!

Je suppose que tu construis tes DLLs en regroupant les fonctions par type de fonctionnalités?
Du coup, "bar" devrait se trouver avec la DLL "fonctionnalités génériques", non?

En tout cas, ça me paraît louche, cette histoire d'allègement de projet par découpage en DLL...
Quel est le contexte?

[bacelar]

Je suis d’accord avec @dragonjoker59, la solution 2 est largement la meilleur.
On appelle cela la "levelisation" des modules.

Cela fait beaucoup de dépendances et complique la relecture.

Absolument pas, bien au contraire, cela ne fait que souligner les faiblesses intrinsèques de votre conception et donne un cadre clair pour les corriger.

[dalfab]

Bonjour,

La 4ème fonctionne, c'est peu courant mais une dll peut dépendre de l'exe

[simac]

Merci à tous de m'avoir répondu !

Il est en effet logique de mettre les fonctions partagées dans une DLL commune, mais qu'en serai-il des fonctions «récursives», par exemple la fonction bar qui appelle la fonction foo ? Il faut donc revoir le code pour les éviter ?

En tout cas, ça me paraît louche, cette histoire d'allègement de projet par découpage en DLL...
Quel est le contexte?

L'utilisation des DLLs n'est pas directement lié à l'allègement du projet, j'ai mal exposé le contexte.
En fait, je suis entrain de reprendre un programme que j'avais écrit en un seul fichier (ou presque) pour le rendre plus lisible et moins long à la compilation. Les DLLs ne sont là que pour permettre de possibles mises à jour.

La 4ème fonctionne, c'est peu courant mais une dll peut dépendre de l'exe

C'est donc à n'utiliser que en dernier recours, mais comment fait-on ?

[bacelar]

mais qu'en serai-il des fonctions «récursives», par exemple la fonction bar qui appelle la fonction foo

Ce cas de figure montre une erreur de conception.
Les Dll et l'exécutable doivent former un arbre ou un graphe sans cycle.
L'exécutable est le point de départ, la racine, il utilise des dll de haut niveau (avec un grand niveau d'abstraction).
Les dll de haut niveau utilisent des Dll de plus bas niveau pour implémenter leurs fonctionnalités de haut niveau.
etc...
L'exécutable pourra aussi utiliser les Dll de bas niveau pour implémenter des propres fonctionnalités.
Mais il est complètement illogique que des Dll de bas niveau, qui doivent donc être utilisables par des Dll de plus haut niveau, utilisent les Dll de plus haut niveau.

Donc, si, légitimement "foo" peut appeler "bar" qui lui-même peut appeler "foo", c'est qu'ils utilisent les mêmes concepts et les mêmes fonctionnalités et donc qu'ils doivent être dans la même Dll.
Mais, bon, ce genre de récursion est souvent suspecte.

Il faut donc revoir le code pour les éviter ?

très souvent, oui.

Si vous découpez votre programme en modules les plus indépendants les uns des autres, vous n'aurez pas grand-chose comme dépendance.

C'est donc à n'utiliser que en dernier recours, mais comment fait-on ?

Un exe, c'est comme une Dll, ça peut exporter des symboles et donc on peut forger une librairie (de dll) avec ses symboles.
Vous donnez cette pseudo librairie à manger au linker lors de la compilation de la Dll.
Mais bon, là, c'est vraiment pour faire le kéké et créer des applications toutes moisies complètement immaintenable.