Discussion :

[daedric]

Bonjour,
Je suis en train de chercher depuis pas mal de temps voir si il etait possible de creer une dll utilisant des fonctions qui seront definis par celui qui le load ?

Typiquement, prenons un serveur web qui charge des plugins, je veux qu'il puisse proposer des fonctions de base (Genre acces aux fichiers, reseau ....) que mes dll pourront utiliser.

Mais est ce possible ? Si oui comment ?

Le but etant bien sur de pouvoir charger une dll sans avoir besoin de recompiler le serveur avec ou de trimballer des .lib ....

Sous un unix-like ya pas de soucis, les symboles non definis sont resolu par le chargeur de programme a l'execution, mais sous windows la dll ne passe meme pas le stade de la compilation.

[Médinoc]

Il y a bien un truc pour les références croisées entre DLLs, mais pour les EXE, je pense que le mieux est encore le passage de fonctions callback en paramètre.
Tu peux proposer toute une "interface" en callback si tu veux; c'est très courant quand on programme avec COM, mais ça peut se faire sans aussi.

[daedric]

Oui c'est mon autre solution mais ca me parraissait tellement aberrant de devoir faire une interface et la passer aux fonctions de ma DLL ...

Merci pour ta reponse

[Mac LAK]

Mets les services "de base" dans une DLL, qui sera utilisée aussi bien par ton programme principal que par les DLL annexes. C'est le plus simple et le plus propre.

[daedric]

C'est aussi une solution mais ca demande de devoir distribuer le .lib et companie.

C'est dans le cadre d'un projet nous demandant de faire un serveur web modulaire multi plateforme. Les modules doivent etre portable au sein de la promo (l'API n'a pas encore ete definis, elle doit etre vote, toussa toussa ...) .

Je pense que le systeme d'interface est le plus simple.

Ceci dit l'idee est interressante, merci

[Mac LAK]

C'est aussi une solution mais ca demande de devoir distribuer le .lib et companie.

Gni ? Pourquoi donc ? Tu peux charger les fonctions en mode JIT, aussi, et donc ne pas avoir besoin de librairie d'importation... Ou tu peux fournir le code d'importation dans une classe définie à 100% dans le .H correspondant à ta librairie "de base", ce qui rend donc son utilisation aussi complexe que d'inclure un .H et d'instancier une classe.
De toutes façons, tu dois déjà distribuer les entêtes de l'API d'interface, donc un peu plus ou un peu moins, je ne vois vraiment pas ce que ça change.

C'est dans le cadre d'un projet nous demandant de faire un serveur web modulaire multi plateforme. Les modules doivent etre portable au sein de la promo (l'API n'a pas encore ete definis, elle doit etre vote, toussa toussa ...) .

Si tu comptes faire un truc portable, déjà, c'est mal barré avec les librairies dynamiques : leur comportement est assez différent entre Linux et Windows, Linux ne connaissant pas la notion de ressources et Windows considérant les DLL comme des exécutables linkés à 100%...
Bref, tu risques d'avoir un problème insoluble dû au fait que les deux OS n'ont pas la même définition d'une "librairie dynamique".

La problématique "plugin" est loin d'être simple, et la rendre portable est en général encore plus complexe.

Je pense que le systeme d'interface est le plus simple.

Plus simple ? Bof... Cela oblige à passer des paramètres en plus à chaque fonction, à gérer les cas d'absence des dites callbacks, à multiplier les déclarations de type fonctionnels, et tu vas rigoler sur la recherche des bugs quand tu te seras trompé de callback. C'est une méthode de programmation qui marche très bien pour des éléments "bas niveau", mais qui montre vite ses limitations sur un code complexe.

L'avantage d'avoir une DLL "bas niveau" partagée entre le programme et les "plugins" du programme, c'est que cette librairie est testable de façon unitaire, et qu'elle sera (à peu de choses près) le seul élément du système contenant du code non-portable, ce qui est loin d'être négligeable. La méthode des callbacks va rendre le code non-portable "tentaculaire" et le disperser dans TOUT le code source, ce qui n'est pas franchement une excellente idée en soi.

[daedric]

Gni ? Pourquoi donc ? Tu peux charger les fonctions en mode JIT, aussi, et donc ne pas avoir besoin de librairie d'importation...

Je ne vois pas comment tu pourrais faire ? Ca resoud pas le probleme comme quoi les dll sont linkees entierement

Ou tu peux fournir le code d'importation dans une classe définie à 100% dans le .H correspondant à ta librairie "de base", ce qui rend donc son utilisation aussi complexe que d'inclure un .H et d'instancier une classe.
De toutes façons, tu dois déjà distribuer les entêtes de l'API d'interface, donc un peu plus ou un peu moins, je ne vois vraiment pas ce que ça change.

Oui ce n'est pas le soucis.

Si tu comptes faire un truc portable, déjà, c'est mal barré avec les librairies dynamiques : leur comportement est assez différent entre Linux et Windows, Linux ne connaissant pas la notion de ressources et Windows considérant les DLL comme des exécutables linkés à 100%...
Bref, tu risques d'avoir un problème insoluble dû au fait que les deux OS n'ont pas la même définition d'une "librairie dynamique".

La problématique "plugin" est loin d'être simple, et la rendre portable est en général encore plus complexe.

On est d'accord, je m'en serais passe mais je n'ai pas le choix.

Plus simple ? Bof... Cela oblige à passer des paramètres en plus à chaque fonction, à gérer les cas d'absence des dites callbacks, à multiplier les déclarations de type fonctionnels, et tu vas rigoler sur la recherche des bugs quand tu te seras trompé de callback. C'est une méthode de programmation qui marche très bien pour des éléments "bas niveau", mais qui montre vite ses limitations sur un code complexe.

Je vois pas ce que ca change concretement entre le fait de passer une interface a une fonction externe d'une dll et le fait que la-dites dll aille piocher elle meme les fonctions dont elle a besoin dans une autre dll.
C'est justement les fonctionnalitees bas niveau que je voulais que la dll aille recuperer dans le serveur.

L'avantage d'avoir une DLL "bas niveau" partagée entre le programme et les "plugins" du programme, c'est que cette librairie est testable de façon unitaire, et qu'elle sera (à peu de choses près) le seul élément du système contenant du code non-portable, ce qui est loin d'être négligeable. La méthode des callbacks va rendre le code non-portable "tentaculaire" et le disperser dans TOUT le code source, ce qui n'est pas franchement une excellente idée en soi.

En fait je sais pas si on s'est entierement compris.
La dans l'etat actuel des choses on a toutes le code non portable realise avec un ensemble d'interface fonctionnant quelque soit la plateforme.

Maintenant il nous manque le gestionnaire de module, on est assez famillier du monde unix mais sous windows on a ete surpris par leurs dll.
On pensait faire le serveur de maniere a ce qu'il propose des fonctions externes pour les fonctionnalitees bas niveau.

Et comme tout semble confirmer qu'on ne peut pas avoir de symboles non resolus, on pensais faire en sorte que les fonctions externes de la dll (et so) prennent en parametres un pointeur sur une interface.

Je vois pas en quoi cela rendrait le code plus tentaculaire.

[Mac LAK]

Je ne vois pas comment tu pourrais faire ? Ca resoud pas le probleme comme quoi les dll sont linkees entierement

Parce que le JIT (Just-In-Time) est un vrai chargement DYNAMIQUE, résolu à l'EXÉCUTION du code correspondant, et non pas réalisé lors de la construction de l'image en mémoire de l'exécutable (=ce qui est fait avant l'appel du main).

Je vois pas ce que ca change concretement entre le fait de passer une interface a une fonction externe d'une dll et le fait que la-dites dll aille piocher elle meme les fonctions dont elle a besoin dans une autre dll.

Interface : des paramètres en plus pour tes fonctions, pour commencer, et la quasi-impossibilité de tester correctement les fonctions bas niveau.
JIT : pas de problème de dépendance circulaire, les entêtes de la DLL peuvent contenir le code d'importation correspondant, et la DLL toute entière peut être testée intensivement de façon autonome.

C'est justement les fonctionnalitees bas niveau que je voulais que la dll aille recuperer dans le serveur.

C'est pour ça que je te parle d'une DLL "bas niveau" pour les stocker. On peut, théoriquement, se linker à des fonctions d'un exécutable comme si c'était une DLL. En pratique, c'est franchement loin d'être gagné.

Et comme tout semble confirmer qu'on ne peut pas avoir de symboles non resolus, on pensais faire en sorte que les fonctions externes de la dll (et so) prennent en parametres un pointeur sur une interface.

Je vois pas en quoi cela rendrait le code plus tentaculaire.

Parce que tu vas "répandre" des références à ces fonctions dans tout le code, notamment lors des appels de fonction, au lieu de les centraliser à un endroit donné (ex : la fonction "WriteToFile" de la DLL bas niveau). Et que le jour où tu dois faire évoluer une de ces fonctions, tu risques de trouver moins drôle d'éplucher tout le code source pour vérifier les références.

Même si la fonction reste "unique", elle est située dans un exécutable, et reste donc non testable de façon unitaire sans modifier le programme les contenant... Ce qui peut (en pratique, "va") introduire des régressions entre le comportement nominal et le comportement en test.

Alors que dans une DLL, tu peux remplacer / corriger une fonction bas niveau sans même avoir besoin de recompiler les programmes qui l'utilisent...

[daedric]

Le JIT ca me parait un peu dur de la faire a la main dans le temps imparti
Et dur tout cours meme.

Pour le fait de placer tout le code bas niveau dans une dll au final ca reviens a ce que tout soit dans l'application 'mere' ce qui est actuellement fait.
C'est vrai que pour les tests c'est moins evident mais les tests unitaires sont deja fait pour chacune des classes.

Je pense que les fonctions exportees des dll recevront une interface en parametres. Ca reste le plus simple et le plus malleable.


Sinon merci pour tes reponses.
On verra bien ce que ca donne .

Desole pour le retard de la reponse j'ai pas recu le mail de notif de reponse