Discussion :

[poukill]

Je reviens à la charge sur de l'inadmissible... Je programmais sur Code::Blocks, ce qui se passait super bien... jusqu'à ce qu'on me fournisse une bibliothèque C (.lib) compilé sous Visual 6.0. Et là c'est le drame.
Même si l'édition de lien se fait correctement, le programme n'effectue point la tâche attendu...
La lib alloue la mémoire pour les objets dans la DLL et la libére dans l'exe ce qui nécessite d'utiliser les bibliothèques multithread de VC++6.0.
Du coup je suis en train de passer sur Visual C++.net 2003.

Est-ce que la librairie devra être recompilé sous C++.net ??? Pourquoi tant d'incompatibilité dans un "même" language pour une DLL???

Merci de votre soutien

[swirtel]

Il ne s'agit pas d'une incompatibilité au niveau du langage, mais simplement du compilateur employé.

Regarde les options de compilation de ta DLL.

[poukill]

Les options de compilation sont pour la bibliothèque RunTime: DLL Multithreads...
Je suppose que, donc, celà invalide tous les autres types de compilateurs pour le reste du développement?
A moins que d'autres compilos utilise ce principe?

J'ai posé la question au gars qui a développé la DLL, il utilise le principe des DLL MultiThreads car la réservation de mémoire est faite dans la DLL, doit être libérée dans l'éxécutable.
Qu'en pensez-vous?
Il n'y a pas d'autres méthodes?

Merci!

[Aurelien.Regat-Barrel]

Non, pas de rapport mono/multithread. C'est lié à la crt, compilée en static ou en dll. La CRT = le code de la lib C/C++, = c'est là que se trouve malloc/free.
Chaque VC++ a la sienne, et MingW a aussi la sienne. Ce qui fait que y'a plusieurs malloc dans ton même processus (celui de l'exe, celui de la dll). Et si tu compile la CRT en static, tu peux même avoir plusieurs fois le même malloc. Dans tous ces cas, ils sont incompatibles, c.a.d qu'il faut utiliser le même couple malloc/free.
Une bonne règle de programmation c'est que celui qui alloue libère aussi. Tu viens de constater pourquoi c'est une règle généralement bonne à suivre.
Une solution simple, c'est que ta dll exporte une fonction Free() que l'exe appelle pour libérer les objets. Le Free() de la dll utilisera en interne son free à elle, qui est associé à son malloc.
Fait une recherche sur le forum VC++ aussi, mots clés CRT, dll, static...

[poukill]

Merci beaucoup, je viens d'aller faire un tour dans le forum, et j'y ai trouvé une mine d'informations.

Une solution simple, c'est que ta dll exporte une fonction Free() que l'exe appelle pour libérer les objets. Le Free() de la dll utilisera en interne son free à elle, qui est associé à son malloc.

La lib étant écrite en C (malloc, free ...). Il faut effectivement libérer la mémoire à la main.
Si elle était écrite en C++ (utilisation de conteneurs de la STL), alors que se passerait-il? (Je subodore qu'il n'y a pas de destructeur implicite...)

Merci de ton aide précieuse, qui m'évitera des memory leaks !

[Aurelien.Regat-Barrel]

La STL suit la même règle : elle va s'occuper de libérer ce qu'elle a alloué elle même, pour ses besoin internes. Si tu lui fait stocker des données que tu as alloué, elle ne les libérera pas pour toi.
http://c.developpez.com/faq/cpp/?pag...elete_sequence
En C++, y'a les pointeurs intelligents qui simplifient le vie:
http://c.developpez.com/faq/cpp/?pag...S_intelligents
mais dans le cas des dll, il faut se méfier... pareil pour la STL et plus généralement les templates qui se marient mal avec les dll.
Par exemple le code suivant:

Code :

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

1
2
3
4
5
6
 
// fonction de la dll
std::string get_text();
 
// utilisation depuis l'exe
std::string s = get_text();

va avoir des problèmes, pour la même raison d'une part, mais encore une autre en plus, qui est celle de l'instanciation des templates (il y a 2 std::string : celui de la dll et celui de l'exe). Là aussi on en a parlé, sur le forum C++ entre autre (warning C4251 de VC++...).

Pour éviter les memory leaks, utilise les smart ptr, mais aussi de manière plus générale l'idiome RAII:
http://c.developpez.com/faq/cpp/?pag...POINTEURS_raii
qui va te faire aimer la programmation en C++