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