Discussion :

[Ekinx93]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[ternel]

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

[Ekinx93]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[koala01]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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

[Ekinx93]

Merci

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

[ternel]

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

[moldavi]

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()).