Discussion :

[troumad]

Bonjour

Je regarde : https://developer.gnome.org/gtk3/sta...uffer-get-text . Mon anglais me pose peut-être encode des soucis... Mais, je ne vois pas si je dois désallouer la mémoire après ? Ou si je dois copier la chaîne et non l'adresse si je veux mémoriser l'état.

[pvincent]

J'ai vu que tu as déjà eu une discussion à propos de newly-allocated dont le sens est clair.
Par contre je trouve la doc

Returns an allocated UTF-8 string

pas claire mais je pense que c'est le même sens, à savoir que c'est à toi de libérer l'espace. Pour ce qui est de mémoriser l'état et continuer à utiliser le buffer en le modifiant, il faut probablement copier la chaîne ailleurs.

[troumad]

Par contre je trouve la doc pas claire mais je pense que c'est le même sens, à savoir que c'est à toi de libérer l'espace. Pour ce qui est de mémoriser l'état et continuer à utiliser le buffer en le modifiant, il faut probablement copier la chaîne ailleurs.

Je trouve que ces deux actions sont contradictoire :
si la mémoire est à libérer, alors, la chaîne envoyée n'a plus rien à voir avec le buffer.

[pvincent]

En fait, il faudrai analyser le code du widget pour être sûr de ce qui ce passe et j'ai un peu la flemme de le faire, surtout qu'on risque d'avoir affaire à la Glib au milieu.

Ce que j'imagine c'est le schéma suivant:
quand le textbuffer est créé, il alloue une chaîne dont le pointeur est retourné par la fonction,
mais si le contenu est modifié, cette chaîne peut être ré-allouée par realloc() et donc le pointeur va changer et le contenu ne sera pas conservé tel quel;
cela ne signifie pas que la cette chaîne est libérée automatiquement ensuite et c'est ta responsabilité de le faire.

Si cela est vrai, il faut donc copier la chaîne si on veut la préserver et libérer soi-même celle (ré)allouée par le widget si on veut éviter les fuites mémoires.

[troumad]

Je suis assez septique quant à la modification dynamique car lors de l'appel de cette fonction on donne un début un une fin. La fin impliquant un 0 de fin de chaîne, le résultat doit être une chaîne allouée qui ne dépendra plus de la zone de texte originale. Je prend ce pari et je ferai des tests.

[troumad]

je crois que la chaîne est allouée spécialement pour. Quand on regarde ceci : https://developer.gnome.org/gtk3/sta...entry-get-text , on voit bien la différence.

On voit aussi la différence pour la compilation :
ceci ne génère pas de warning :

Code :

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

_perso->perso.commentaire=gtk_text_buffer_get_text(texte,&debut,&fin,TRUE);

Ceci en génère un :

Code :

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

_perso->perso.sociale=gtk_entry_get_text(GTK_ENTRY(gtk_builder_get_object(_perso->modif->builder,"sociale")));

Et je dois mettre ceci :

Code :

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

_perso->perso.sociale=g_strdup(gtk_entry_get_text(GTK_ENTRY(gtk_builder_get_object(_perso->modif->builder,"sociale"))));

[pvincent]

J'ai essayé de remonter à la main dans le source de gtk+-3.12.2 la chaîne des appels en supposant que la longueur du buffer à varié et cela donne:

Code :

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

1
2
3
4
5
6
7
8
gtk_text_buffer_get_text ()
gtk_text_iter_get_text ()
_gtk_text_btree_get_text ()
copy_segment ()
g_string_append_len ()
g_string_insert_len ()
g_string_maybe_expand ()
g_realloc ()

Sauf erreur de ma part, cela voudrai dire que dans ce cas, on tombe bien sur g_realloc () qui modifie la valeur du pointeur, donc, si tu te contente de stocker l'ancien pointeur, il n'est plus valide.

[liberforce]

C'est dans ce but qu'il existe des annotations dans le code source, utilisées pour l'introspection. Ainsi les différents bindings générés peuvent extraire les caractéristiques des fonctions à partir de mots clés. Exemple: gtk_text_buffer_get_tag_table, qui est dans la même classe, mais a lui l'annotation "transfer-none". En passant la souris sur cette annotation, on voit que cette fonction ne renvoie pas un pointeur à libérer.

En revanche, "transfer-full" indique que l'appelant est responsable de cela mémoire et doit la libérer. C'est ce que devrait avoir gtk_text_buffer_get_text, c'est donc peut être juste un petit bug de documentation de gtk_text_buffer_get_text, mais le texte est quand même assez explicite. La fonction en elle même ne peut de toute façon pas renvoyer un pointeur vers la chaîne en cours d'utilisation (où serait le caractère nul de fin de chaine ? Comment masquer les caractères invisibles ?), c'est donc forcément une copie pour les besoins ponctuels de l'appelant.

Plus d'infos sur les annotations ici:
https://wiki.gnome.org/Projects/GObj...on/Annotations

Le code source de GtkTextBuffer:
https://git.gnome.org/browse/gtk+/tr...tktextbuffer.c