Discussion :

[DSGSLA]

Bonjour,

J'ai �crit une librairie en C++, destin�e � �tre appel�e depuis un progiciel. Les types de retours accept�s sont ceux du C : int, short... et le char*.
Plusieurs de mes fonctions sont de type char *. La taille de la cha�ne n'�tant pas pr�visible, je fais donc des new. Mais je ne peux faire appel au delete ni avant le return (le pointeur ne pointe vers rien d'existant) ni apr�s (l'ordre est ignor� par le compilateur).
A chaque appel de la fonction de l'espace est r�serv� mais non lib�r�. Je pr�sume que cette action doit �tre effectu�e au niveau du programme appelant. Dans le progiciel un appel de fonction des librairies est trait� ainsi :

Code :

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

1
2
type_string_propriétaire ma_variable;
ma_variable = appel_ma_fonction(paramètres)

ma_variable est un objet statique, puis-je lui appliqu� un delete ?
La lib�ration sur l'espace point� par appel_ma_fonction se fera-t-elle ?
Comment traite-on en g�n�ral ce probl�me d'appel de char* dans une librairie ?

[screetch]

en g�n�ral malheureusement on le traite mal.

les exemples les plus frequents sont d'avoir des fonctions "new" et "delete" pour les cr�er et les lib�rer, et demander au clinet (le progiciel) de bien penser a liberer quand ils n'ont plus besoin de l'objet (ce qu'ils ne font en g�n�ral pas)

par exemple dans gtk, cela ressemble a

Code :

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

1
2
3
4
w = get_widget_new("MyWidget", parent, 0, 0, 320, 200);
gtk_widget_show(w);
...
gtk_widget_destroy(w);

et c'est comme ca pour tous les types C publi�s.

Si tu peux te le permettre, ton meilleur choix est de renvoyer des types C++ comme std::string.

[DSGSLA]

Le progiciel m'impose les types possibles, donc pas de std::string, ce qui m'impose d'ailleurs de souvent faire des conversions std::string->char*

[screetch]

ben malheureusement, a ma connaissance, pas de magie

[bacelar]

Si tu peux te le permettre, ton meilleur choix est de renvoyer des types C++ comme std::string.

Cela implique un progiciel en C++ avec la STL, et en plus la m�me stl et le m�me compilateur que ceux de la lib.

Pour des probl�matiques de lib�rations, je vois l'utilisation des Handles en retour des fonctions de la lib, des fonctions qui permettent de les utiliser et lib�rer impl�ment�es dans la lib.
Si le langage du progiciel permet le RIIA, des smart pointeurs peuvent peut-�tre �tre pratiques.

[Grulim]

Ca d�pend du nombre d'allocation que tu fais, mais tu peux peut-�tre g�rer une liste qui contient les pointeurs sur les zones de m�moire allou�es.
Puis au d�chargement de ta librairie, tu fais le m�nage dans cette liste...

[DSGSLA]

La fonction est appel�e par le progiciel pour chaque ligne du flux entr�e, qui peut atteindre des millions de lignes, d'o� le probl�me de m�moire.

[bacelar]

Il appel bien une fonction quand il arrive � la fin du fichier et il appel bien une fonction quand il n'a plus besoin de la valeur retourn� par la fonction appel�e � chaque ligne.

[Grulim]

Soit tu responsabilises les utilisateurs de ta lib et tu cr�es une fonction qui permette la d�sallocation.
Ou alors... tu utilises un ramasse-miettes.

[Mac LAK]

La fonction est appel�e par le progiciel pour chaque ligne du flux entr�e, qui peut atteindre des millions de lignes, d'o� le probl�me de m�moire.

Pas tant que �a, le probl�me... De toutes fa�on, faudra les lire et les maintenir en m�moire tant qu'il en a besoin, OK ?

Donc : en interne, tu maintiens une map / liste des cha�nes allou�es, et soit l'utilisateur les d�truit "proprement" (tout va bien), soit tu vides toi-m�me tout ce qui tra�ne � la fin du processus (fa�on garbage collector), une fois que tu es certain que les cha�nes ne sont plus n�cessaires. Cela va certes bouffer un max de RAM, mais d'un autre c�t�, l'utilisateur peut �galement limiter pas mal la casse s'il utilise proprement ta librairie. En tout cas, de ton c�t�, tu t'assures que tu n'auras pas de fuite m�moire au moins.

Sous Windows, tu peux aussi te cr�er un tas priv� dans lequel faire les allocations, et qui te permettra alors de tout lib�rer d'un seul coup en d�truisant le tas priv� (cf. HeapAlloc). Je ne sais pas s'il existe un �quivalent sous *nix.

[DSGSLA]

Le serveur tourne sous AIX.
Pour persuader l'�diteur de modifier son produit il faut que les modifications qu'il aurait � faire, du type une seule ligne "delete variable".
L'ordre delete sur un objet statique est-il licite ?

[Grulim]

Le serveur tourne sous AIX.
Pour persuader l'�diteur de modifier son produit il faut que les modifications qu'il aurait � faire, du type une seule ligne "delete variable".
L'ordre delete sur un objet statique est-il licite ?

si celui-ci a �t� allou� avec un new... Ca me parait de plus en plus un pb de conception de l'API
Je vois mal un client faire un delete sur un pointeur retourn� par une fonction d'une librairie tiers, c'est sale !
Il vaut mieux faire une fonction qui encapsule cette fonctionnalit�... apr�s tout, seule l'�diteur sait r�ellement ce qu'il faut faire (plusieurs delete, des free, des flags � remettre � 0, ...)