Discussion :

[Serry99]

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

[koala01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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();
}

[Médinoc]

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

[Mat007]

Salut,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[koala01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[Médinoc]

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.

[Serry99]

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

[cedriclyon]

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

[Emmanuel Deloget]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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'.

[Médinoc]

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