Ecrire une DLL C++ avec des parametres string en entr�e

bonjour
je suis vraiment d�butant en C++, j'ai r�cup�r� un bout de code tel que Myfunction re�ois deux nombres et retourne la somme des deux nombres

int __stdcall MyFunction(int nFirstNum, int nSecondNum)
{
return nFirstNum + nSecondNum;
}

Seulement je voudrais �crire une DLL qui y ressemble mais la fonction devra recevoir deux parametres string � peu pr�s de cette mani�re

int __stdcall MyFunction(Char FirstCHAR, Char SecondCHAR)
{
// ici je re�ois par exemple FirstChar="CB01220" et SecondCHAR="ALA-56- 19920" et je fais mon traitement

return (0);
}

merci de votre aide

Salut, et bienvenue sur le forum

Sois attentif � ce que tu �crit:

"CB1220" et "ALA-56- 19920" ne sont pas des char (qui sont le type caract�re), mais, sont � consid�rer, au minimum comme des "tableau de caract�res", au maximum comme "des chaines de caract�res".

En C++, on pr�f�re utiliser la classe string, disponible dans l'espace de noms std par inclusion du fichier d'en-t�te <string>, pour la gestion des chaines de caract�res, car elle permet de faciliter et de s�curiser �norm�ment la tache.

Cependant, dans le cas tout particulier des dll's, il faut comprendre que, id�alement, une dll devrait pouvoir �tre compil�e avec un compilateur particulier, mais �tre utilis�e dans un projet qui, lui, serait compil� avec un compilateur diff�rent.

Or, la norme laissant �norm�ment de libert�s aux programmeurs de compilateurs, il n'est pas impossible que la classe std::string de l'un ne soit pas impl�ment�e de la m�me mani�re ce celle de l'autre, ce qui emp�cherait d�s lors cette "interop�rabilit�" (et qui n�cessiterait d�s lors de compiler la dll pour chaque compilateur particulier, r�duisant d�s lors � n�ant tout l'avantage que l'on peut en tirer).

il est donc d�s lors pr�f�rable que toute fonction accessible depuis l'ext�rieur de la dll n'utilise que des types priimitifs, ou des pointeurs vers des types primiftifs.

Au final, il est fort possible de partir sur un code ressemblant � (en ayant d�finit par macro pr�processeur MYEXPORT � __decl(dllexport) pour la compilation de la dll)

Code:

---

1 2 3 4 5 6 7 8

int MYEXPORT MyFunction(const char* s1, const char* s2) { //pour manipuler les chaines plus facilement std::string recupstr1(s1); std::string recupstr2(s2); /* tu fais ton traitement ici */ return 0; }

---

ou, si la valeur de retour doit �tre une chaine de caract�res, cela pourrait ressembler �

Code:

---

1 2 3 4 5 6 7 8 9 10

const char* MYEXPORT MyFunction(const char* s1, const char* s2) {   //pour manipuler les chaines plus facilement std::string recupstr1(s1); std::string recupstr2(s2); std::string result;//chaine de résultat à renvoyer /* tu fais ton traitement ici */ return result.c_str(); }

---

Quelques pr�cisions sur l'export pour les fonctions et les classes :
http://www.developpez.net/forums/sho...42&postcount=6

Salut,

Citation:

---

Envoy� par koala01

Code:

---

1 2 3 4

std::string result;//chaine de résultat à renvoyer /* tu fais ton traitement ici */ return result.c_str();

---

---

Le pointeur retourn� n'est plus valide d�s que result est d�truit (en fait d�s que result est modifi� m�me)...

MAT.

Citation:

---

Envoy� par Mat007

Salut,


Le pointeur retourn� n'est plus valide d�s que result est d�truit (en fait d�s que result est modifi� m�me)...

MAT.

---

De fait... cela nous oblige donc � un code du genre de

Code:

---

1 2 3

char *ret=new char[result.size()]; memcpy(ret,result.c_str()); return ret;

---

avec obligation de g�rer la lib�ration de la m�moire dans les fonctions qui r�cup�re ce pointeur :question:

Je comprend de mieux en mieux ce que je n'aime pas dans les DLL's 8O

En fait, le probl�me majeur des DLLs est simple: Elles ne sont pas adapt�es au C++, et il n'y a pas de standard ind�pendant du compilateur.

Les DLLs MFC marchent parce qu'elles ne sont utilis�es que sous Visual.

De plus, ce qui est allou� par une DLL doit �tre d�truit par la m�me DLL.
C'est pourquoi, quand une fonction dans une DLL doit retourner une cha�ne, soit elle prend un buffer et une taille en entr�e, soit elle donne une fonction pour la d�truire.

Bonjour
comme je d�bute en c++, j'ai repris donc "litt�ralement" le premier code puis le 2me de koala01 mais � la compile j'ai deux error dont voici les messages

error C2146: syntax error : missing ';' before identifier 'MyFunction' et fatal error C1004: unexpected end of file found

la suite des r�ponses � question ne m'a pas bcp aid� � avancer

Est-il possible d'avoir un code "correct" pr�t � �tre ex�cut�, cela m'aide bcp dans ma compr�hension, c'est ce que je faisias � mes d�buts en VB.net, je r�cup�rais des bouts de codes valides et je travaillais dessus pour arriver au traitement final recherch�.

Merci de votre aide

A vrai dire, c'est parce que j'ai sans doute manqu� quelque peu de pr�cision dans mes �crits.

Pour te permettre de comprendre l'ensemble du probl�me, il semble utile de t'expliquer clairement toute la probl�matique des biblioth�ques dynamiques, du moins sous windows.

En effet, pour qu'une fonction pr�sente dans une biblioth�que dynamique soit utilisable de l'ext�rieur, il faut qu'elle soit export�e par la biblioth�que dynamique.

Et, "fatalement", pour qu'un programme sache qu'il a affaire � une fonction venant de la biblioth�que dynamique, il faut lui demander... de l'importer.

Cela signifie que, lorsque tu compile ta biblioth�que, la d�claration (et la d�finition) des fonctions doit �tre du genre de

Code:

---

typeDeRetour __decl(dllexport) nomFonction(/*paramètres éventuels */)

---

mais, que de l'autre cot�, lorsque tu fournis le fichier d'en-t�te � l'utilisateur de ta biblioth�que de mani�re � ce qu'il puisse l'utiliser de son cot�, son compilateur doit trouver la d�claration (et la d�finition) sous la forme de

Code:

---

typeDeRetour __decl(dllimport) nomFonction(/*paramètres éventuels */)

---

La diff�rence �tant minime, autant attirer ton attention dessus...

Dans le premier code, ce qui est se trouve entre les parenth�ses qui suivent __decl est dllexport, alors que c'est dllimport dans le second code.

Evidemment, tu me diras qu'il est tout � fait possible de pr�voir deux fichiers d'en-t�te diff�rents (vu que ce sont les seuls qu'il faut fournir en plus de la dll), l'un qui sera utilis� pour compiler la dll et l'autre qui sera fournit � l'utilisateur...

Mais, m�me si c'est possible, il faut quand m�me avouer que �a repr�sente pas mal de travail pour pas grand chose :P

L'id�e est donc d'appeler saint pr�processeur � la rescousse, car il va g�rer cela tr�s facilement.

L'id�e est, tout simplement de lui dire que, si on lui indique qu'il est occup� � travailler � la compilation de la biblioth�que dynamique, il doit remplacer un terme choisi pour �tre unique (ici MYEXPORT) par __decl(dllexport), et que, sinon, il doit remplacer ce terme par ... __decl(dllimport).

Il reste alors juste � savoir comment nous allons signaler au pr�processeur que nous sommes occup�s � compiler la dll...

Ce sera fait en fournissant une option -D (ou /D selon le compilateur) pour define, suivie d'un terme explicite, par exemple "BUILD_DLL", et cela prendrait donc la forme de

Code:

---

gcc -DBUILB_DLL(tout le reste de l'instruction)

---

Au final, l'instruction pr�processeur serait du genre de

Code:

---

1 2 3 4 5

#ifdef BUILD_DLL #define MYEXPORT __decl(dllexport) #else #define MYEXPORT __decl(dllimport) #endif

---

que l'on veillera � placer dans un fichier qui sera inclus partout o� risque d'apparaitre le fameu MYEXPORT

Si tu avais pris la peine de lire le lien fourni par M�dinoc, tu n'aurais pas eu moins d'explications ;)

Tu peux aussi envisager de lire le chapitre d�di� � la gestion des dll dans l'excellent article de Laurent Gomilla, sans oublier que :google: ou la fonction rechercher sur le forum sont des amis tr�s utiles pour les membres du forum.

Evidemment, s'il reste quelque zones d'ombre malgr� tes recherches personnelles, n'h�site pas � nous faire part de tes interrogations ;)

Au fait, une petite question en passant: y a-t-il une raison primordiale qui te fasse te tourner vers une DLL plut�t que vers une biblioth�que statique, dont la gestion reste malgr� tout bien moins complexe :question:

Citation:

---

Envoy� par koala01

De fait... cela nous oblige donc � un code du genre de

Code:

---

1 2 3

char *ret=new char[result.size()]; memcpy(ret,result.c_str()); return ret;

---

avec obligation de g�rer la lib�ration de la m�moire dans les fonctions qui r�cup�re ce pointeur :question:

Je comprend de mieux en mieux ce que je n'aime pas dans les DLL's 8O

---

Non - parce que tu forces l'utilisateur � lib�rer la m�moire. Hors, rien n'oblige l'utilisateur a utiliser le m�me runtime dans la DLL et dans le programme appelant. De fait, au moment de la destruction de la chaine de caract�re allou�e, il est probable qu'une corruption de la pile ou du tas se produise (�a arrive notamment sous Visual C++ si on mixe les mod�les de compillation single-threaded debug, multithreaded debug, single-threaded release, multithreaded release, single-threaded debug DLL, multithreaded debug DLL, single-threaded release DLL, et multithreaded release DLL (DLL == utilisant le CRT sous la forme d'une DLL). Comme on voit, la multiplicit� des mod�les fait qu'on a de forte chance de se retrouver dans un mauvais cas).

C'est la raison pour laquelle les API Windows pr�f�re passer les chaines de r�sultat en param�tre de la fonction appel�e:

Code:

---

error_code_type my_function(param1, ..., char* out_string, int out_string_max_len);

---

De cette mani�re, l'appelant est responsable de l'allocation et de la d�sallocation. Par contre, cela oblige la fonction appel�e � v�rifier si
* out_string est valide
* la taille maximale de out_string est suffisante pour stocker le r�sultat de la fonction.
Dans le premier cas, la fonction renvoie g�n�ralement un code d'erreur du type 'param�tre invalide'. Dans le second cas, elle renverra un code du type 'la taille n'est pas suffisante'.

Comme je l'ai dit, on peut s'en sortir en retournant un pointeur, du moment qu'on expose une fonction pour supprimer.

Exemples dans Windows:

• Les BSTR, cr�es et d�truites par OleAut32.dll (SysAllocString()/SysFreeString()).
  Dans le m�me genre, on peut compter aussi les SAFEARRAY (SafeArrayCreate()/SafeArrayDestroy()) et CoTaskMemAlloc()/CoTaskMemFree()
• FormatMessage() avec le flag FORMAT_MESSAGE_ALLOCATE_BUFFER retourne un pointeur qu'il faut lib�rer avec LocalFree().
• Un objet COM s'efface lui-m�me lors du dernier Release() (fonctions virtuelles/pointeurs de fonction).

Exemples ailleurs:

• La biblioth�que DispHelper exporte des fonctions qui retournent des cha�nes, ainsi qu'une fonction dhFreeString().

je vous remercie pour vos r�ponses qui semble pour un vrai de vrai d�butant cmme moi un peu compliqu�es. Pour r�sumer, je vous envoi ce tutorial
http://www.programmers-corner.com/tutorial/4

dans cette exemple la DLL re�ois en entr�e deux chiffres et return leur somme

Tout simplement, j'aimerais faire la m�me chose sauf qu'au lieu des chiffres ce sera des chaines de caract�res telles "C0001245" et "AER-02-1992" en entr�e et en sortie msgbox (C0001245 AER-02-1992)

Donc si vous pouviez m'envoyer le source en d�tail ( les lignes � mettre dans .h, .def et .cpp comme l'exemple du tutorial) pour que la DLL s'ex�cute se serait sympa et cela m'aiderai bcp � avancer dans mon projet.

depuis mon premier message et grace notamment � vos r�ponses, j'ai pas mal avanc� dans la compr�hension des DLL mais concretement c'est encore en chantier, sans doute que la compr�hension viens en s'exer�ant.

Merci de votre aide

Citation:

---

Envoy� par Serry99

dans cette exemple la DLL re�ois en entr�e deux chiffres et return leur somme

Tout simplement, j'aimerais faire la m�me chose sauf qu'au lieu des chiffres ce sera des chaines de caract�res

---

Il y a d�j� un param�tre de type cha�ne de caract�res dans l'exemple, c'est szString.
Qu'est-ce qui te bloque exactement ?

MAT.

si tu regardes bien le programme VB le szstring est indiqu� en dur alors que mes deux chaines de carat�res (parmetres re�us ) sont des variables, c'est � dire je recois par exemples le couple "C14578" "ALE-04-1954" une autre fois "Bz1235" "QZE-04-4532" etc etc

mon traitement commence par une lecture d'un fichier, je r�cup�re les deux chaines de caract�res (les fameux param�tres) que je transmet � ma DLL qui fait un traitement.

j'ai bien essayer de remplacer dans le programme VB le szstring en dur par une vaiable qui concat�ne telle C1="C14578 ALE-04-1954" mais la DLL plante

Mon probl�me donc et de pouvoir �crire en gros ceci
MyFunction(char parm1, char parm2)
Return parm1, parm2
{
et dans le programme VB, j'�crirais ceci
Private Declare Function MyFunction Lib _
"c:\temp\debug\maDll.dll" (ByVal parm1 As String, _
ByVal parm2 as string) As string

Private Sub Form_Load()
Dim lngResults As string ( au lieu de Long)
lngResults = MyFunction(Parm1, parm2)
MsgBox CStr(lngResults)
Unload Me
End Sub

Citation:

---

Envoy� par M�dinoc

En fait, le probl�me majeur des DLLs est simple:
De plus, ce qui est allou� par une DLL doit �tre d�truit par la m�me DLL.

---

Bonjour, je serais int�ress� pour avoir plus de pr�cisions sur les raisons.

Merci ;)

Citation:

---

Envoy� par cedriclyon

Bonjour, je serais int�ress� pour avoir plus de pr�cisions sur les raisons.

Merci ;)

---

cf #9 dans la m�me page.

On peut ajouter que l'ABI du programme appelant peut �tre diff�rente de l'ABI de la fonction appel�e. Par cons�quent, mieux vaux laisser l'appel� effectuer les op�rations sur la m�moire qu'il a cr��.

De plus, une DLL avec une interface C peut �tre utilis�e dans n'importe quel langage qui supporte les DLL. Question: comment d�salouer une zone m�moire allou�e avec l'op�rateur new dans un programme �crit en VB?