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.

[simac]

OK, donc les «récurences» sont à bannir et les appels à l'exécutable aussi.

Mais bon, là, c'est vraiment pour faire le kéké et créer des applications toutes moisies complètement immaintenable.

C'est toujours bien de connaître les raccourcis, mais mieux vaux prendre les chemins balisés ^_^

Je passerai donc par les DLLs communes, celles de bas niveau et celles de haut niveau.

Résolu ? Possibilités de rajout ? Si certains connaissent d'autres moyens, qu'ils n'hésitent pas !

[bacelar]

OK, donc les «récurences» sont à bannir

Non, des récurrences entre modules/dll de niveau d'abstractions différentes, oui, c'est l'appel d'une Dll de bas niveau vers une Dll de haut niveau qui n'est pas bon.

et les appels à l'exécutable aussi.

Ailleurs que depuis le code de l'exécutable, oui à éviter comme la peste.

[jblecanard]

Au vu de l'exposition du contexte, je ne vois pas pourquoi tu choisis d'utiliser des DLL. Pour "permettre des mises à jours" ? Une DLL est utile si elle est partagée et/ou si elle est chargée dynamiquement. Je crois comprendre que tu n'es dans aucun de ces cas. Du coup, je n'utiliserais aucune DLL. Tu peux découper ton fichier en header et en unités de compilation sans passer par des bibliothèques.

[bacelar]

Une DLL est utile si elle est partagée

En les "levelisant", elles deviennent partageables.

[simac]

Le partage des DLLs n'est pas mon but premier; je les utilises pour les charger dynamiquement (sinon, ça n'a pas beaucoup d'avantage par rapport à une bibliothèque statique). Je n'aurai pas parlé de DLL si je voulais les charger en statique, j'aurai utilisé header et fichiers sources.

[jblecanard]

En les "levelisant", elles deviennent partageables.

Certes, mais est-ce souhaitable ? De ce que je comprend de la situation de @simac, il cherche à structurer son code. A moins qu'il n'aie des dizaines de milliers de lignes à organiser, découper tout ça en DLL alors même que le produit final est l'exécutable me semble être du zèle. C'est du travail en plus pour bien organiser les DLL entre elles, sans aucun apport fonctionnel.

Après si le but est de s'entraîner à l'exercice, pourquoi pas, c'est une bonne raison

[Médinoc]

Si ton projet contient des cycles, c'est souvent un problème de conception pouvant être résolu par le principe d'inversion des dépendances (dependency inversion)

[simac]

Mon projet n'est effectivement pas aussi gros, il fait presque 10000 lignes

il cherche à structurer son code

Oui

découper tout ça en DLL alors même que le produit final est l'exécutable

Justement, le produit final est l'exécutable plus les DLLs

Après si le but est de s'entraîner à l'exercice, pourquoi pas, c'est une bonne raison

Aussi !

[bacelar]

L'utilisation de Dll a l'ENORME avantage d'obliger la levelisation des modules.
Donc même si c'est pour en faire des librairies statiques en fin de compte, il aura vérifié automatiquement que sa conception tient la route.
La conversion d'un projet Dll en projet lib statique, c'est quelques minutes.
Si une librairie statique n'est pas convertible en Dll à cause de dépendance cyclique, c'est que la conception est merdique et qu'il faut la corriger.
Et une manière de vérifier la correction, c'est d'en faire une Dll, au moins temporairement.

En résumé, avec des lib statiques, on peut programmer comme un sagouin, avec une Dll, un peu moins.

[simac]

Ça fait un bon proverbe ça ! ^^