Dll avec m�thodes utilisant des strings

Bonjour

D�butant en c++ j'ai suivi les conseil d'un tuto trouv� sur internet qui m'a permis de faire une dll et d'appeler ses m�thodes dans divers language (Delphi, Windev etc. )sans avoir a faire de regsvr ou autre manip sur la dll....parfait.

La ou �a bloque c'est quand j'essai de faire des m�thodes utilisant des strings

Voila le code du tuto qui fonctionne

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include "stdafx.h"       extern "C" __declspec(dllexport) unsigned long int factorielle(int n) { unsigned long int resultat = 1; if(n < 0) return -1; if(n == 0) return 1; for(; n > 0; n--) resultat *= n; return resultat; }

---

Serait il possible d'avoir un petit exemple avec une string.

Par avance merci

std::string n'est pas du C, donc ne peut pas �tre utilis�e dans extern "C" {...}Au choix, tu supprimes le extern "C" ou tu oublie string dans l'interface

Merci pour la r�ponse, cela me fait progresser.
Ceci dit impossible d'initialiser correctement une variable de type string

supposons que je veuille faire une fonction qui re�oit une chaine en param�tre et retourne une chaine apr�s manupulation.

un truc du genre

Code:

---

1 2 3 4 5 6

extern __declspec (dllexport) TypeChaine MaFonction(Chaine nom_du_parametre) { action quelconque sur la chaine   return resultat; }

---

Comment devrais m'y prendre pour la d�clarer.

Par avance merci

Salut,

G�n�ralement, on utilise quelques directives pr�processeur conditionnelles pour faire en sorte que tout se fasse automatiquement.

En effet, une fonction (export�e depuis une dll) ne vaut que si l'utilisateur est en mesure... de l'importer.

Il faut donc, d'abord et avant tout, avoir un fichier d'en-tete qui permette, lors de la compilation de la dll, d'indiquer qu'une fonction (ou une classe, car cela marche aussi avec les classes et les structures ;)) sera effectivement export�e et, lors de l'utilisation de la dll, d'indiquer que la fonction (ou la classe) doit bel et bien etre import�e.

Et, tant qu'� faire, comme les conventions d'appel __declspec(dllexport) et __declspec(dllimport) sont propres � windows et inconnues sous linux, on peut aussi faire en sorte que le symbole que l'on d�finit vaille... simplement rien si on compile sous linux ou si on compile le code pour en faire une biblioth�que statique ;)

Au final, on �crira un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// _WIN32 et _WIN32_ sont deux symboles utilisés sous windows #if defined(_WIN32) || defined(__WIN32__) // on ajoute un define automatique "SHARED" aux options de compilation # if defined(SHARED) // on choisit un symbole qui ne sera utilisé que lors de la compilation de la dll # if defined(BUILD_MYDLL) // si toutes ces conditions sont remplies, il faut exporter la fonction/ les classes # define MYDLL_API __declspec(dllexport) # else // sinon, on utilise la dll, il faut importer les fonctions / les classes # define MYDLL_API __declspec(dllimport) # endif // BUILD_MYDLL // si SHARED n'est pas défini, on travaille avec une bibliothèque statique // la convention d'appel peut etre vide # else # define MYDLL_API # endif // SHARED #else // si on ne compile pas sous windows, la convention d'appel est inutile, tant // pour les bibliothèques statiques (lib*.a) que pour les bibliothèques dynamiques (*.so) # define MYDLL_API #endif //_WIN32 or _WIN32_

---

que l'on placeras fichier d'en-tete (souvent appel� mylib_api.h) que nous inclurons dans tous les fichiers d'en-t�tes dans lesquels nous d�clarerons une fonction ou une classe que nous voulons utiliser de mani�re externe � la dll.

Cela donnerait (en consid�rant que le fichier s'appelle mylib_api.h) quelque chose comme
fichier1.h

Code:

---

1 2 3 4 5 6 7 8

#include <mylib_api.h> // exporter une fonction void MYLIB_API laFonctionDeLaMortQuiTue(std::string const & str); // exporter une classe entière class MYLIB_API MaClass { // tout ce qu'il faut };

---

et en cr�ant, bien entendu, le fichier d'impl�mentation correspondant (dans lequel il est inutile de rappeler MYB_API ;))

Le fichier d'impl�mentation sera alors compil� en rajoutant les options -DBUILD_MYDLL et -DSHARED (version "g++") ou /DBUILD_MYDLL et /DSHARED (version "VC++") et, quand il s'agit d'utiliser la dll, les fichiers d'impl�mentation seront compil�s avec la seule option -DSHARED (ou /DSHARED avec VC++)

Note cependant qu'une dll compil�e � partir d'un code C++ ne peut etre utilis�e qu'avec du code qui sera compil� avec le m�me compilateur de la m�me version que le compilateur avec lequel la dll a �t� compil�e.

En effet, les symboles export�s (ou importables) sont "entour�s" de signes plus ou moins cabalistiques en C++, � cause des possibilit�s de cr�er des fonctions membre et de surcharger les fonctions. (en anglais, on parle de mangling), alors que les symboles export�s (et importables) issus du C ne doivent pas fournir le moyen de savoir si on appelle la version prenant un int ou un float de la fonction, car il n'y a pas moyen de surcharger les fonctions.

Le probl�me, c'est que les symboles qui entourent les fonctions ne sont absolument pas standardis�s et peuvent parfaitement changer d'une version � l'autre d'un m�me compilateur et peuvent donc �tre tout � fait diff�rents d'un compilateur � l'autre.

Tu comprends sans doute maintenant le pourquoi de cette restriction ;)

Si tu veux que le contenu d'une dll puisse etre export� et import� avec n'importe quel compilateur, toute version confondue, il faut imp�rativement faire en sorte que les fonctions soient consid�r�es comme devant respecter les conventions du C.

Pour y arriver, on peut exporter uniquement les fonctions libres en les d�clarant extern C, � condition cependant de n'utiliser dans leur signature que... des �l�ments issus du C.

On peut, cependant, parfaitement utiliser des �l�ments de C++ dans le corps des fonctions, vu qu'elles seront, quand meme, compil�e avec le compilateur C++ ;)

Hope it helps ;)

Merci

Je vais �tudier tout cela...et je vais bien finir par comprendre.

Merci koala01, je ne suis pas un sp�cialiste des biblioth�ques partag�es, ton explication m'est pr�cieuse.

Citation:

---

Envoy� par Ekinx93

Serait il possible d'avoir un petit exemple avec une string.

---

Oui c'est possible, mais il y a juste un ou deux petits probl�mes. Si on parle bien des string de la stl, seuls les programmes en C++ peuvent les reconna�tre. Donc exit les autres langages.

Je l'ai d�j� fait, mais il me semble que c'est avec une dll COM, pas une dll classique (dll en C++ et programme appelant en C++). (et j'ai eu des probl�mes entre les versions Release et Debug. On ne pouvait pas mixer les deux, � cause des options de compilation de la classe string, un truc du genre String_Secure...).

En gros, cela ne sert � rien de vouloir g�rer des string dans une dll. Des langages comme Delphi, C#, etc... ne savent pas ce qu'est une classe string de la stl.

Il faut utiliser les char* ou les wchar* ou const char*, etc...

Dans ta dll, tu peux utiliser les string de la STL. Mais dans les m�thodes expos�es, tu retournes des char* ou autres (voir string.c_str()).