Discussion :

[guillemouze]

Salut a tous,
étant en migration d'une application Delphi (7) vers C++ & Qt, j'arrive sur ce sujet, et je préfère m'assurer du comportement qu'aura mon application.
D'abord, ma question : Est il dangereux d'utiliser une dll qui uses ShareMem dans une application qui ne le uses pas, si on n'utilise pas de fonctions avec des String ?

Le contexte est le suivant :
j'ai une application principale, et plusieurs autres qui doivent interagir avec cette première. Toutes ces applications sont actuellement en Delphi 7.
Pour avoir cette interaction, l'app principale fournit une dll, qui utilise ShareMem (de même que tous les app satellites).
L'une de ces app passant en C++ & Qt, il faut que je fasse quelques modifications pour que la dll soit compatible avec tout le monde (NB : les applications peuvent évoluer sur une machine indépendamment les unes des autres).
Mon idée est de rajouter des fonctions utilisant des PChar, en plus des String. De cette manière, tout la monde continue de fonctionner avec cette nouvelle dll.
Par exemple, ma dll ressemblera à ca :

Code :

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

1
2
3
procedure SetNumero(ANum: integer); stdcall;//inchangé compatible avec les 2
procedure SetAdresse(AAdresse: string); stdcall;//pour les anciennes apps
procedure SetAdressePChar(AAdresse: PChar); stdcall;//pour la nouvelle app

Étant donné que les anciennes apps utilisent toujours les strings, ma dll doit uses-er SharMem, mais mon app C++ ne le uses-era forcement pas. Y a t'il un risque à cela ? C'est dur d'en être sûr en testant car les erreurs liées a SharMem n'apparaissent pas à tous les coups.

Merci de votre éclairage.

[Paul TOTH]

si l'API n'utilise plus que des PChar, ShareMem n'est plus nécessaire.

pour faire simple ShareMem permet à l'EXE de libérer une zone mémoire allouée par la DLL et vice et versa.

cela concerne donc GetMem/FreeMem, SetLength, et donc aussi les strings.

si la DLL ne cherche pas à libérer une zone mémoire de l'EXE ou qu'elle est responsable de la libération de tout ce qu'elle alloue, tu supprimes ShareMem.

[guillemouze]

Je ne peux pas supprimer ShareMem car j'ai des fonctions de compatibilité qui utilisent toujours des string. Mais si mon exe n'utilise que les fonctions PChar (en paramètre et en retour), je peux laisser ShareMem dans la dll sans risque ?
Ce que je me dis, c'est que l'exe doit initialiser le gestionnaire de mémoire de borlandmm.dll, or si il n'utilise pas ShareMem, le gestionnaire n'est pas dans un état viable, et les potentielle allocations de string, même simplement dans le corps d'une fonction de la dll, peut causer un problème.

si la DLL ne cherche pas à libérer une zone mémoire de l'EXE ou qu'elle est responsable de la libération de tout ce qu'elle alloue, tu supprimes ShareMem.

Et si je suis dans ce cas, mais que je ne supprime pas SharMem, pas de problème ?

[Paul TOTH]

si je comprend bien tu as un exe sans sharemem qui utilise une DLL qui l'exploite...ben oui tant que la DLL ne récupère pas un type dynamique de l'exe elle n'a aucune raison de chercher à la libérer.

attention cependant aux déclarations, tu peux très bien avoir cette déclaration dans la DLL

Code :

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

1
2
 
procedure test(p: PChar);

et celle-ci dans l'exe

Code :

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

1
2
 
procedure test(const s: string); external 'dll';

dans les deux cas c'est un pointeur sur le premier caractère d'une chaîne qui se termine (aussi) par #0

vu que la DLL pense que c'est un simple PChar elle n'en fera rien de spéciale, et vu que l'exe déclare la string en "const", il ne s'attends pas à ce qu'elle soit modifiée par la DLL, donc tout va bien

par contre si tu déclares que c'est un string dans la DLL elle peut aller voir du côté des offsets négatifs et foutre le zone.

[guillemouze]

Ok super.
Merci pour la réponse Paul.