SIMPLE MOYEN DE FAIRE UNE DLL À PARTIR DE FONCTIONS CPP , Source N°18418

Information sur la source

Catégorie :Tutoriaux Niveau : Débutant Date de création : 04/12/2003 Vu / téléchargé: 9 723 / 918

Auteur : vieuxLion

Ecrire un message privé

Note :

10,00 / 10

1
2
3
4
5
6
7
8
9
10

Commentaire sur cette source (9)

Ajouter un commentaire et/ou une note

Description

Suite à une question dans ma messagerie, voici un SIMPLE moyen de récupérer des fonctions déjà écrites en C++ et de les regrouper en une DLL.

1) Extraire les fonctions désirées dans un fichier : fonctions.cpp
Remarque, il n'est pas nécessaire de modifier leur prototype
Exemple :
double Ajouter(double x, double y){return x+y;}
double Soustraire(double x, double y){return x-y;}

2) exporter les fonctions de la DLL :
Il s'agit de créer un fichier "fonctions.DEF"
Exemple :
LIBRARY    petiteDLL
EXPORTS   Ajouter
          Soustraire

3) Fabriquer la DLL :
On pourra créer un fichier "make.bat" ainsi :
rem Compilation
CL.exe /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /Y- /Fo"fonctions.obj" /FD /c fonctions.cpp
rem /MT pour lien avec LIBCMT.LIB (Multi-Thread)

rem LINK
link.exe /nologo /dll /machine:I386 /def:".\fonctions.def" /out:petiteDLL.dll /implib:"petiteDLL.lib" fonctions.obj

4) Créer un fichier d'entête pour les EXEs clients de la DLL
Il suffit de regrouper les prototypes des fonctions dans un fichier "fonctions.h"
double Ajouter(double x, double y);
double Soustraire(double x, double y);

5) On livrera au client la DLL, la librairie d'import et le fichier d'entête soit :
petiteDLL.DLL, petiteDLL.LIB et fonctions.h

Conclusion

La question exacte portait sur la fabrication d'un outil d'Automatisation pour générer des DLLs à partir du code de fonctions écrites dans des fichiers CPPs

Le problème n'est pas très simple :
il s'agit de déterminer QUELLES fonctions exporter (peut être pas "main" ! )
il s'agit ensuite de les repérer pour en extraire :
- le corps pour le .CPP
- le prototype pour le .H
- le nom pour le .DEF
et peut-être le plus délicat... importer au link les .LIB nécessaires

Voici la technique microsoft : placer les .LIB les plus fréquemment utilisés
au niveau du link, il peut être nécessaire de prendre en compte des librairies statiques contenant les fonctions utilisées par votre code
Exemple :
link.exe kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 /def:".\fonctions.def" /out:petiteDLL.dll /implib:"petiteDLL.lib" fonctions.obj

vérifer avant d'utiliser les .BAT que les variables d'environnement du compilateur sont configurées

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

fonctions.cpp 101 octets
fonctions.def60 octets
fonctions.h 77 octets
makeDLL.bat 284 octets
MakeTest.bat 212 octets
petiteDLL.lib1 994 octets
test.cpp 205 octets

Télécharger le zip

Sources du même auteur

Toutes les sources de vieuxLion

Sources de la même categorie

Toutes les sources de la catégorie Tutoriaux

Commentaires

Commentaire de magic_Nono le 04/12/2003 15:53:32

merci pour cette réponse, VieuxLion

je m'y colle et d'ici une semaine, j'espere arriver à qqch

Nota: je suis en train de réaliser un soft: MétaProgramme
permettant de gérer des srces, donc la plupart des primitives sont là...
@ très bientôt sur cette page
Nono.
Commentaire de BruNews le 04/12/2003 18:32:23 administrateur CS

Salut l'ancien, quel mauvais vent t'avait eloigne de Codes-Sources ?
Commentaire de vieuxLion le 04/12/2003 19:00:36

Merci de noter mon retour
j'en suis heureux
On va dire ... beaucoup de travail et c'est super

j'en profite pour rajouter (à l'article sur les DLLs) qu'en l'absence de DllMain, le compilateur le génèrera lui-même

Mes sincères salutations
Commentaire de magic_Nono le 09/12/2003 18:59:01

Salut à vs nos vénérables..... maîtres......
.   [Tu ne vénerera que ton Seigneur Dieu]
.      pas vénérable alors mais en cas merci pour le coup de paluche

Bien...
Le soft avance mais n'est pas encore parfait:
- Comment le linker peut-il liéer plusieurs fonctions ayant le même nom & un prototype différent sachant que seul le nom est transmis au .def (exemple: plsr constructeurs...)
(échec du linkage avec mes derniers exemples...)
- qu'est sencée faire l'option /Y-, elle n'est pas acceptée par le CL.exe de VC++6.0

sinon, le pb des fichiers obj à inclure est résolu...: je permet de les sélectionner... avt le linkage

Rq: les classes crées avec visual demandent l'intégration d'un fichier 'stdafx.h' qui n'est pas forcément présent... apparement, ce fichier serait utilisé pour des directives de compilation(?)

Rq2: DLLMain??? en tt cas, cette fonction n'est pas visible avec l'explorateur de DLL livré avec Visual

Rq3: Non, je n'ai rien pour cet outil de Krosoft, mais en tt cas, il est pratiQ...

Kenavo.         Nono.
Commentaire de vieuxLion le 09/12/2003 22:52:49

OK :
pour lier des fonctions surchargées (même nom+args différents), il faut (hélas) changer de technique d'export
le .DEF ne décore pas les noms
il faut passer par la technique "Microsoft" : ajouter le modificateur __declspec(dllexport) devant le prototype

/Y- est bien une option de VC++6 : elle signifie ne pas utiliser les En-Têtes précompilés

Le fichier 'stdafx.h' sert par défaut de marqueur pour séparer les headers inclus dans le précompilé (le .PCH) qui doivent être positionnés avant 'stdafx.h' et les autres exclus de .PCH inclus après :
#include "inclusDansPCH.H"
#include "stdafx.h"
#include "exclusDePCH.H"
il est possible de changer ce nom dans les Settings de projet / C++ /precompilated headers
Commentaire de magic_Nono le 10/12/2003 11:17:14

C domage, je pensais laisser les srces intactes...
Et il va faloir qq tps pour adapter la 2nde meth...

Nota pour les adeptes du __export :
les macros __declspec(dllimport) et __declspec(dllexport) de VC++32bits replacent le mot clef __export de VC++ 16bits

Nota: je viens de trouver la note suivante:
_______________________________________
The major disadvantage of using .a DEF file is that if you are exporting functions in a C++ file, you will either have to place the decorated names in the .DEF file or define your exported functions with standard C linkage by using extern C to avoid the name decoration done by the compiler.
If you need to place the decorated names in the .DEF file, you can obtain them by using the tool DUMPBIN or by using the link switch /MAP. Note that the decorated names produced by the compiler are compiler specific. If you place the decorated names produced by the Visual C++ compiler into a .DEF file, applications that link to your DLL must also be built using the same version of Visual C++ so that the decorated names in the calling application match the exported names in the DLLs .DEF file.
_______________________________________
Si G bien compris, cela signifie que l'on peut utiliser les noms décorés dans le .def...
. dsl VieuxLion,

Et ce qui suit nous dis bien que les DLL générées par .def sont préférables pour une application distribuée(srce: msdn)
_______________________________________
Using __declspec(dllexport) is convenient because you do not have to worry about maintaining a .DEF file and obtaining the decorated names of the exported functions. However, you do not have control over the export ordinals that the compiler generates. This method is suitable if, for example, you are designing a DLL for use with an application that you control; if you rebuild the DLL with new exports, you will also have to rebuild the application.
_______________________________________
(et en general, C le mm développeur qui développe la DLL et son appli, mais ça peut poser des pb si on veut distribuer les dll pour développer avec...)

Pour le module makeDLL de MétaProg,
je ferai par défaut un .def sans déclaration et je le décorerai ssi il y a des doublons...

PS: je suis bien d'accord pour ne pas utiliser les En-Têtes précompilés
mais l'option /Y- n'est vraiement pas acceptée...
Commentaire de magic_Nono le 13/12/2003 14:28:56

PS je n'arrive pas à faire fonctionner la déco
et les const/dest ne sont pas accetés...
Polké???
Commentaire de vieuxLion le 13/12/2003 15:34:05

salut,
la technique du .DEF ne fonctionne bien que dans les limites du langage 'C'
dans le cas de surcharge et de const , etc ... enfin tout ce qui est accepté en C++ mais pas en C, il est possible d'utiliser les noms décorés mais ce n'est vraiment pas pratique. (f@aE56...)
Une autre solution est de créer des fonctions Wrappeurs
par exemple de générer deux noms différents pour la fonction 'f' surchargée suivante
void f()
void f(int)
on peut envisager f1 et f2 ou bien f_void et f_int

pour cette technique de Wrapping, regarde cette source que j'ai faite il y a un moment :
http://www.cppfrance.com/code.aspx?ID=10423
Commentaire de magic_Nono le 17/12/2003 11:15:38

Voici le produit en l'état actuel...
http://www.cppfrance.com/code.aspx?ID=18782

mais il comporte effectivement les limitations dues au C

et les constructeurs/dest... ne passe pas

et le mode décoré ne semble pas parfait...

Rq: la solution proposée pour l'absence de l'option /Y- est la création de plsr fichiers 'stdafx.h'

Voila, on continue donc les com sur l'autre page....
Kenavo
Nono