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