[grisbi-devel] Patches à commenter

[Pierre Biava]

Sylvain Glaize écrivait le 12/03/2011 18:06 :

Bonsoir,

Merci pour tes patchs. Je les ai intégrés dans la branche master.

> j'ai lancé un petit valgrind/memcheck aujourd'hui sur la dernière
> version du dépôt. Cela sort par mal de choses. Je voulais m'en servir
> comme point d'entrée pour comprendre le code de grisbi.

C'est une bonne façon de faire.
> - spelling.patch : simplement des corrections dans les commentaires. Par
> contre, je n'ai pas bien saisi ce qu'étaient ces auto_func et à quoi
> elles servaient.

OK

> - file_config.patch :
>
> ** j'ai sorti le g_free() du #ifdef, car je ne vois pas la raison pour
> laquelle le g_free() ne serait pas fait sur Win32

Maintenant que tu les dis moi non plus mais je n'ai guère le temps de 
chercher ce type de problème.



> De manière plus générale, je m'aperçois que memchecker envoie pas mal
> d'erreur suite à des allocations de chaînes via g_strdup et ses copains.
> Le code de grisbi est parsemé de g_free() et il est assez facile d'en
> oublier.

C'est vrai qu'il faut être rigoureux et prendre le temps de faire les 
choses proprement. Ce que je ne fais pas toujours :-(

> Est-ce qu'il a été déjà question d'utiliser un autre schéma ? Est-ce
> considéré comme un mal nécessaire ? (je ne connais pas les pratiques
> classiques en programmation gtk).
Propose on verra si c'est plus pratique.

> - free_variables.patch :
>
> la première modification est une toute petite factorisation de code, qui
> était dupliqué. Je pense que c'est un schéma de code dupliqué qui existe
> à bien d'autres endroits.

d'une manière générale dans chaque fichier on accède directement aux 
variables globales plutôt que de passer par la fonction d'interface ce 
qui doit permettre de gagner du temps mais je n'ai jamais fait de mesures.

> J'ajoute une fonction pour libérer l'allocation sur la font transaction.
> Ça n'est pas complètement nécessaire, il n'y a pas de leak, juste une
> ressource pas libérée à la sortie, mais pour voir les vrais problèmes
> avec memcheck, il est intéressant de nettoyer les semi-problèmes qui
> polluent le log.
>
> Correction d'un commentaire de fonction.
>
> Ces fonctions retournent un gboolean dont la valeur n'a pas de sens et
> n'est d'ailleurs pas utilisée sur les appels direct. Mais il est fait
> mention de la compatibilité avec les auto_func. D'où ma question sur ce
> que sont les auto_func.

Les auto fontions permettent d'économiser des lignes de code en créant 
des widgets avec les appels aux callbacks associés et la mise à jour des 
variables associées c'est très pratique même si ça déroute quand on 
commence à étudier le code de Grisbi.
> Dans main.c, avant de sortir, appel de la libération des variables (pour
> le moment uniquement celle que j'ai traitée).

En fait on ne sort pas par cette fonction sauf sortie du gestionnaire de 
fenêtre. A ce propos je n'ai pas trouvé comment bloquer cette sortie 
avant d'avoir sauvegardé les modifications de Grisbi.

Sinon on sort par la fonction main_window_delete_event () et dans cette 
fonction on traite la libération de la mémoire avec la fonction 
init_variables () mais ce n'est pas exhaustif compte tenu de tout ce 
qu'on perd.

Bonne continuation dans ton exploration correction du code de Grisbi.

-- 

A+

Pierre Biava