Gestion des fichiers XML avec GT
Par Bernard SIAUD
Le 2013-03-04 08:59:43, par djibril, Responsable Perl et Outils
Bonjour,
Voici un nouvel article : Gestion des fichiers XML avec GTK+ de Bernard SIAUD.
Merci de donner vos avis et commentaires.
Voici un nouvel article : Gestion des fichiers XML avec GTK+ de Bernard SIAUD.
Merci de donner vos avis et commentaires.
-
liberforceModérateurMes remarques:
- le mélange d'anglais et de français dans le programme est assez malheureux. Je conseille à tout le monde de coder en anglais exclusivement en anglais (quitte à mettre les commentaire en français). On évite les problèmes d'accents, de position des verbes, et on favorise l'homogénéité.
- l'article évoque l'utilisation de GTK alors que seule la GLib est ici utilisés.
- l'auteur ne tire pas parti de la puissance de la GLib. À quoi sert str_isspace quand la libc fournit isspace et la GLib g_ascii_isspace ? Et mintexte quand la GLib fournit g_strstrip ?
- il y a une typo dans GmarkupDomContext où Markup devrait commencer par une majuscule.
L'article ne parle pas non plus d'une grosse limitation de GMarkupParser, pourtant évoquée dans la première ligne de l'aide officielle:
Simple XML Subset Parser — parses a subset of XML
Je ne suis pas rentré dans le détail du XML (pas le temps), mais je vois des constructions comme:
Code : 1
2if (root->fils>fils) if (root->child[fils].item==(fils+texte+com)) {
Il semble aussi avoir vu des mallocs au lieu de g_malloc (malloc peut renvoyer NULL, là où g_malloc arrêtera le programme si la mémoire manque), etc.le 07/03/2013 à 17:17 -
liberforceModérateurCertain. C'est dans la doc de g_try_malloc. C'est d'ailleurs l'origine de la différence de sémantique: g_try_malloc dit "essaie de m'allouer de la mémoire" (et n'échoue pas si tu n'y arrives pas), là où g_malloc dit "alloue moi de la mémoire" (et tue le programme si tu n'y arrives pas). Le comportement de malloc est (cf man 3 malloc):
The malloc() and calloc() functions return a pointer to the allocated memory that is suitably aligned for any kind of variable. On error, these functions return NULL. NULL may also be returned by a successful call to malloc() with a size of zero, or by a successful call to calloc() with nmemb or size equal to zero.
g_try_malloc quant à lui sert à essayer d'allouer de gros buffers, si on n'est pas sûr d'avoir la mémoire suffisante pour cela.le 14/03/2013 à 19:59 -
liberforceModérateurPas de soucis.
Pour la doc de g_try_malloc:
gpointer g_try_malloc (gsize n_bytes);
Attempts to allocate n_bytes, and returns NULL on failure. Contrast with g_malloc(), which aborts the program on failure.
n_bytes : number of bytes to allocate.
Returns : the allocated memory, or NULL.
gpointer g_try_malloc (gsize n_bytes);
Tente d'allouer n_bytes octets, et renvoie NULL en cas d'échec. Contraste avec g_malloc(), qui termine le programme en cas d'échec.
n_bytes : nombre d'octets à allouer.
Renvoie : la mémoire allouée, ou NULL.
Les fonctions malloc() et calloc() retournent un pointeur vers la mémoire allouée qui est allignée de manière appropriée à n'importe quel type de variable. En cas d'erreur, ces fonctions renvoient NULL. NULL peut aussi être renvoyé par un appel réussi à malloc() avec une taille de zéro, ou par un appel réussi à calloc avec nmemb ou size égal à zéro.le 16/03/2013 à 16:21 -
liberforceModérateur
Code : 1
2
3
4
5
6
7#define INDENT(niv) \ do \ { \ gint i; \ for (i = 1; i < (niv) - 1; i++) \ g_print ("\t"); \ } while (0)
Code : 1
2
3
4
5
6
7#define INDENT(level) \ do \ { \ gint i = level; \ while (i-- > 0) g_print ("\t"); \ } while (0)
le 07/03/2013 à 17:35 -
troumadRédacteur/ModérateurMerci !
Il va falloir que je regarde ça ! Mais, en ce moment, le boulot me demande beaucoup !
Je viens de regarder les commentaires. C'est vrai que je ne suis pas allé aussi loin dans l'étude du programme. Comme je l'ai indiqué en début d'article, j'ai juste corrigé et commenté un programme qui était proposé ici et peu utilisable en l'état car
1) il manquait d'explications
2) il avait quelques bugs
Je vais essayer aussi rapidement que possible de profiter de ces remarques pour améliorer ces fonctions que j'utilise par ailleurs. Je vais peut-être aussi rajouter une ou deux fonctions que j'ai développées pour la lecture des ods à partir de celles déjà écrites ici.
Sinon, pour les noms en anglais, je suis tellement ignare en anglais que je préfère mettre des noms en français.le 07/03/2013 à 18:17 -
troumadRédacteur/ModérateurCe code est plus rapide, mais le "while (i-- > 0)" me semble peut lisible ! J'ai plutôt tendance à dire à mes étudiants d'oublier la différence entre i++ et ++i afin de rendre lisible le code. Ici, si on met --i à la place de i--, on aura une tabulation de moins. Je ne sais si ça vaut le coup de pousser l'optimisation à ce point.le 08/03/2013 à 17:14
-
troumadRédacteur/ModérateurJe regarde la doc. Es-tu sûr de ce que tu dis ? Tu ne parlerais pas plutôt g_try_malloc (ou g_try_realloc)
Je continue de travailler tes remarques dès que j'ai du temps
je viens de trouver l'origine de mon travail : http://subversion.developpez.com/pro.../gmarkup-dom.c
https://developer.gnome.org/glib/2.3...et-Parser.html pour les limitations. Comme j'avoue que je suis arrivé à travailler sans problème les fichiers que je voulais modifier (des fichiers odt et ods), je ne m'étais pas rendu compte de limitations.le 09/03/2013 à 10:53 -
troumadRédacteur/ModérateurMa fonction dit qu'une chaîne entière correspond à un espace alors que g_ascii_isspace signale uniquement si un caractère est un espace.
Par contre, mintexte est remplacé sans problème par g_strstrip.
Avant de passer à la modification de l'article, il faudra que je trouve l'origine de la fuite de mémoire du programme qui utilise ces fonctions. Il faudrait que je m'assure que ça ne vienne pas de là !
La fuite est là : http://www.developpez.net/forums/d13...fuite-memoire/ .le 09/03/2013 à 17:57 -
troumadRédacteur/ModérateurOK... Encore un e fois, mon anglais me fait défautle 14/03/2013 à 20:56
-
troumadRédacteur/ModérateurTon commentaire précédent m'avait suffit pour comprendre la subtilité du problème. Mais, merci pour cette traduction !le 16/03/2013 à 19:04