Discussion :

[xChRiSx]

Salut,

J'ai un ptit soucis sur la mise en place d'un système de plugin pour un programme de traitement d'images.

Depuis mon programme j'appelle une DLL qui contient une fonction 'process' ( qui va manipuler la valeur des pixels d'une ou plusieurs images).
Jusque là pas de soucis.

Mais lorsque j'essaye d'utiliser une classe appartenant à mon programme dans cette DLL, ça foire au moment du link :
MaClasse* x; //Marche
x->f(); //Link Error

D'où ma question :
Est-ce possible de compiler une DLL en utilisant un fichier .obj existant ( celui ou maClasse est définit ) ?
Connaissez vous une meilleur façon de procéder ( je pensais faire une lib exprès pour cette DLL, mais ça risque d'être long surtout que suis débutant dans ce domaine ).

Je précise que je suis sous visual studio 7.0 ( shared MFC DLL)


Merci de m'avoir lu,

a+



EDIT : Bon j'ai réussi pour les obj, ça compile mais c'est vraiment vilain ( obligé de rajouter 4 fichiers obj dans additional dependencies )

[r0d]

Bonjour,

il y a 2 façons, sous windows, d'utiliser du code compilé en dehors de l'application: une lib statique (.lib) ou une lib dynamique (dll). L'avantage de la première est que c'est plus confortable pour le développeur, l'avatange de la seconde est que l'on est pas contraint de recompiler l'appli lorsqu'on modifie la lib (idéal donc pour un système de patch et surtout de plug-in).

Lorsque tu compiles ta dll, le code résultant ne comporte que le minimum d'informations concernant le contenu de cette dll, à savoir l'adresse des fonctions qui y sont implémentées. Il est donc indispensable de récupérer les adresses de ces fonctions pour pouvoir les appeler.

Pour ce faire, il faut définir un .def dans le projet de ta dll. Ce .def définit toutes les fonctions que tu souhaites exporter. Le mieux c'est que ce .def porte le même nom que la dll générée. Ce .def va ressembler à ça:

Code :

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

1
2
3
4
5
LIBRARY	"MaLib"
 
EXPORTS
    Fonction1        @1
    Fonction2        @2

Pour charger ta dll, tu dois alors utiliser la fonction LoadLibrary(), qui te retourne un handle sur cette dll. Note: tu dois connaitre le nom et l'emplacement de cette dll pour pouvoir appeler LoadLibrary().

Un fois cette lib chargée, tu va devoir retrouver tes fonctions en utilisant la fonction GetProcAddress, et lui donner le nom de la fonciton en paramètre. GetProcAddress retourne un pointeur sur ta fonction.

Si tu veux récupérer une classe, il va te falloir implémenter quelque chose du style MaClasse* GetInstance(); et du coup, pas besoin d'exporter toutes les fonctions membres de ta classe.

Il y a certainement des oublis et des erreurs dans ce que je te dis là, il y a longtemps que je n'ai plus utilisé le mécanisme des bibliothèques dynamiques, mais n'hésites pas à poser des questions.

Hope it helps.

[Médinoc]

Je pense que tu es un peu à côté.

La méthode la plus simple pour utiliser une DLL C++, c'est de lier ton projet "utilisateur" à la bibliothèque statique d'importation créée en même temps que la DLL (ou livrée avec). Il s'agit généralement d'un fichier .lib avec le même nom que la DLL.
L'inconvénient de cette méthode, c'est que la DLL doit absolument avoir été produite par le même compilateur, pour des raisons de name mangling.

L'autre méthode est celle employée par COM/OLE, expliquée ici :
[Résolu] Chargement d'une DLL

[GEIIMAN]

si tu veu que ta DLL utilise un objet de ton programme, il te faut faire connaitre a celle ci l'adresse de l'objet en question grâce a un pointeur par exemple.

[xChRiSx]

Salut !

Désolé pour ma réponse tardive , au boulot j'ai pas le net et j'ai pas trop eu le temps cette semaine.

J'ai résolu mon problème en utilisant une petite structure commune à ma DLL et mon programme.
C'est pas super joli niveau conception mais rapide à mettre en place ( je devais finir mon stage aujourd'hui ).


@r0d : Merci pour ta réponse très instructive et d'avoir prit de ton temps pour me répondre.

@Médinoc : Merci pour ces précisions ( même si mon soucis n'était pas lié à l'importation de ma DLL dans le projet ).

@GEIIMAN : yup, et comme le disait r0d le mieux aurrait été de faire une 2eme DLL et de récupérer les adresses via GetProcAddress.


Merci à vous,
a+.

[r0d]

Je pense que tu es un peu à côté.

La méthode la plus simple pour utiliser une DLL C++, c'est de lier ton projet "utilisateur" à la bibliothèque statique d'importation créée en même temps que la DLL (ou livrée avec). Il s'agit généralement d'un fichier .lib avec le même nom que la DLL.
L'inconvénient de cette méthode, c'est que la DLL doit absolument avoir été produite par le même compilateur, pour des raisons de name mangling.

Et puis, le truc c'est que lorsque l'on souhaite utiliser les dll pour faire des plugins, le chargement des dll se fait forcément à l'exécution (en général, l'application scanne un dossier et charge les dll présentes dans ce dossier) car on ne sait pas, à la compilation, quelle dlls sont à charger. La lib d'import n'est donc d'aucune utilité dans ce schéma.

[Médinoc]

Je dois avouer que j'avais mal lu ton précédent post.
En tout cas, ce que tu as dit sur le MaClasse * GetInstance() méritait de préciser que toutes les fonctions membres à importer doivent être virtuelles.