Bonjour.
 
J'essaye desespérément depuis plus d'une semaine de faire une dll compatible en C mais qui en interne est en C++
 
j'ai reussi a la créer et a l'utiliser sous visual.
 
mais quand je tente de l'utiliser sous CVI (compilateur C) je bloque sur le probleme suivant :
 
j'ai 2 fonctions voici le .H de ma dll :  
 
________________________________________________
 
#ifdef __cplusplus
    extern "C" {
#endif
 
 int  __declspec(dllexport) _stdcall InitGdiplus(void);
 void __declspec(dllexport) _stdcall CloseGdiplus(void);
 
#ifdef __cplusplus
    }
#endif
 
________________________________________________
 
j'ai egalement un .def :  
 
________________________________________________
 
LIBRARY LSGdiplus
 
EXPORTS
 
InitGdiplus
CloseGdiplus
 
________________________________________________
 
Et donc sous CVI lorsque j'appelle l'une de ces fonction le compilateur me jete en me répondant :  
 
undefined symbol '_InitGdiplus@0' not defined in main.c
undefined symbol '_CloseGdiplus@0' not defined in main.c
 
j'ai essayé plusieurs choses comme par exemple de mettre dans mon .def :
 
InitGdiplus = _InitGdiplus@0
 
mais rien n'y fait et pourtant je me répéte, sous visual je ne rencontre aucun probleme pour appeller ces fonctions.
 
Je pense qu'il doit y avoir un parametre a modifier dans le projet sous visual pour résoudre ce probleme de nom décoré.
 
Dernier détail, si je regarde ma dll je vois ceci :  
 
pour le premier .def :  
 
Export Table
 
 Name: LSGdiplus.dll
 Characteristics: 00000000
 Time Date Stamp: 408bd341
 Version: 0.00
 Base: 00000001
 Number of Functions: 00000002
 Number of Names: 00000002
 
Ordinal Entry Point Name
0000 00001080 CloseGdiplus
0001 00001030 InitGdiplus
 
pour le second .def (cad en mettant InitGdiplus = _InitGdiplus@0):
 
Export Table
 
 Name: LSGdiplus.dll
 Characteristics: 00000000
 Time Date Stamp: 408bd341
 Version: 0.00
 Base: 00000001
 Number of Functions: 00000004
 Number of Names: 00000004
 
Ordinal Entry Point Name
0000 00001080 CloseGdiplus
0001 00001030 InitGdiplus
0002 00001080 _CloseGdiplus@0
0003 00001030 _InitGdiplus@0
 
mais pourquoi tant de haine?
voila ma balize de détresse est lancée.

T'as vraiment besoin d'un DLL ? Une lib tout simple statique serait pas plus pratique dans ton cas ?
 
Cordialement,  
 Xter.
 

euh bonne question
 
bah en fait je suis en stage en entreprise, c'est ce que l'on m'a demandé, c'est pour pouvoir utiliser gdiplus.dll qui est gratuit plutot que la dll payante de CVI.
 
je ressort d'un formation ou j'ai juste appris le C++ traditionnel et encore!! je n'ai pas vu: les STL , MFC, sigleton, heritage multiple, et les exeptions.
 

Si je comprends bien la DLL dont tu nous parles ne t'appartient pas, et on peut raisonnablement penser qu'elle est correctement codée. Ta question est donc comment de manière gfénérale utliser une DLL dans ton programme ? C'est bien ca ?
 
La DLL est livrée avec quoi d'autre : .def, .h ?

Pourquoi as tu besoin d'un .def??
C'est plus d'actualité, ça.
A+,

xterminhate : gdiplus est plus que raisonnablement codée a mon avis, elle est carrement fournie de base avec VC 2003
 
gilou: et bien parceque je me suis basé sur un code donné en exemple, sur les dll je suis autodidacte a 100%
 
J'avoue que je maitrise pas grand chose dans tout ca, il m'a semblé comprendre que le .def servait a exporter les fonctions sous forme non décorés, mais j'ai essayé aussi sans le .def car (j'ai encore cru comprendre que ) mes __declspec(dllexport) suffisent a exporter mes fonctions.

le C quoi

j'oubliais, meme avec le code que mon "patron" m'a donné en exemple je rencontre EXACTEMENT le meme probleme.

 
bah non !  
j'ai vu les classes, surcharge d'operateur, heritage simple, polymorphisme, classes et fonctions template, donc non pas du C

j'ai pas d'expérience C++ utilisé par du C, mais je sens assez mal si y a des RTTI (virtual, dynamic_cast, etc) vu que ça demande un support d'exécution...

j'ai ultra vaguement vu les RTTI, en fait pour un exercice il nous expliquait comment l'utiliser.

ben le polymorphisme ça demande des RTTI
 
d'ailleurs le extern "C" je l'ai jamais utilisé que pour déclarer du code C avec lequel je voulais linker, je suis pas sur du tout qu'on puisse s'en servir pour exporter du code ...

et bien c'est exactement ce que je cherche a faire, exporter des fonctions en C qui apres en interne de la DLL (donc "invisible" pour le C) appellent ce qu'il faut comme il faut.

je sais même si c'est possible ...
 
je viens de faire un test : sur un truc très simple comme  
 

ça marche
 
maitenant le simple fait d'inclure <iostream> fout tout en l'air alors ....
 
 

j'ose pas penser

je comprends même pas comment le premier exemple passe, puisque le deuxième me crache indéfiniment
 

 
ça sent le dtc profond là

Les .def, ca date de l'epoque ou microsoft n'avait pas les __declspec(dllexport)
Ca faisait la meme chose: declarer explicitement les noms des procedures appelables depuis l'exterieur (ie declarer les procedures exportees de la dll).
(Bon, un .def, ca fait aussi d'autres choses, qui sont parametrables aussi directement au niveau du compilo ou du linker)
Donc, utiliser les deux, ca fait double emploi, et ca risque meme de creer des pbs inutiles.
A+,

 
CVI, kesako??
Tu as bien fait une lib associee a la DLL et tu linkes avec elle??
A+,

 
L'utilisation de dllexport et d'un fichier .def est redondante. C'est soit le dllexport, soit le .def. Enfin pour le C, pour le C++ seul dllexport permet l'export de classes.
 
Le problème vient donc peut-être de là. Il faudrait essayer de construire le projet sans le .def
 
Sinon ça pourrait éventuellement être un setting de compilation qui forcerait les conventions d'appel dans le projet de la dll et pas dans l'autre ...

Tout d'abord, Merci les gars c'est vraiment sympa de me donner un coup de pousse.
 
Bon alors dans l'ordre des questions :
 
gilou : CVI est un soft de "National instrument" plutot dédié au monde de l'industrie c'est un IDE reposant entierement sur le C tu achete les librairie a la carte, certaines servent d'interface pour diverses capteurs de mesure, ce que je trouve genial avec CVI en tant que débutant, c'est que tu peux avec une facilitée enfantile créer des interfaces utilisateurs, tout se fait a la souris, ca t'ouvre pour chaque ellement de l'IUM une fenetre de parametres que tu saisi et ca te genere le code, a l'inverse depuis le code tu peux retourner dans ces fenetres de parametres, c'est tres intuitif et simple d'utilisation. Tu peux d'un simple clic demander a CVI qu'il te genere une dll compatible visual.
 
pour le lib, bah c'est un projet dll win32 donc quand je compile , oui ca me genere un .lib et voici comment apres j'importe ma dll :  
 
tout d'abord je copie le .dll dans system32, le .lib dans /lib/ de visual et dans /extlib/ de CVI, et enfin le .h dans /include/ de visual et de CVI.
 
je fais dans mon code un #include "madll.h", et dans les proprietes de mon projet, editeur de liens, entrée, dépendance supplementaire je met : madll.lib
 
c'est le seul moyen que je connaisse a l'heure actuelle pour importer la dll.  Petite précision, dans cvi je n'ai pas trouvé d'endroit où l'on peut specifier le .lib, j'ai placé ce fichiers dans le repertoire extlib, j'ai egallement essayé en le placant dans le répertoire du projet comme ca a été fait dans le code que l'on m'a donné en exemple et qui lui fonctionne.
 
fli : oui moi aussi je pense que ca doit etre un parametre a la con dans mon projet visual qui pose probleme et voici pourquoi je pense ca :  
si je me base sur l'exemple qui m'a été donné, et que je laisse tous les parametres du projet de ma dll par defaut, j'arrive a compilé mais quand je crée un nouveau projet console dans visual et que je tente d'importer puis utiliser les fonctions de ma dll, alors le compilateur de visual me sort la meme erreure de compilation que sous CVI : undefined symbol '_InitGdiplus@0' not defined in main.c  
 
du coup j'ai comparé 1 a 1 les parametre du projet donné en exemple avec ceux d'un projet vide et grace a ca, j'ai résolu le probleme sous visual, mais je le répéte sous CVI le probleme reste entier.
 
voici les parametres concernés (je les ai betement tous relevés certains sont plus que certainement inutile, principalement concernant les chemins avec Debug, mais bon...):  
 

 
si pour l'un de ces parametres vous savez quelles concequences cela peut avoir sur mon probleme pourriez vous me l'expliquer brievement?

honte a moi je vais me faire harakiri.
mon probleme etait un faux probleme, tout etait ok en fait, j'ai finallement trouvé, le pb se trouvait dans CVI j'ai trouvé comment lui donné a bouffer le .lib j'aurais du m'en douter tout de suite et ne pas m'egarer dans des hypotheses foireuses quand j'ai constaté que sous visual le probleme n'existait pas !
 
donc pour résumer pour exporter des fonctions d'une dll vers du C, il faut :
1) fixer les parametres du projet comme décrit ci dessus
2) dans le header procéder de la facon suivante :
 

 
et evidement la definition des fonctions dans le cpp doit coincider avec les prototypes dans le header.