> Il me semble qu'un GString, c'est tout bêtement une structure avec un char* et un gint (pour la longueur) dedans, ie il y a aucune notion d'encodage dans le GString non plus.
A mon sens, le fait d'utiliser une structure speciale signale au developpeur qu'il peut y avoir des questions a se poser et lui font soulever plus vite la question de l'encodage utilise.
Tu peux te dire que le mec qui rencontre une gstring la premiere fois, il va aller voir la documentation et il va tomber sur le paragraphe qui dit que toutes les gstring sont codes en utf8 et va verifier qu'il n'a pas de problemes speciaux de conversion. Le mec qui rencontre un char * pour la premiere fois n'est pas pret de contribuer a Gnome (il a encore qqes mois devant lui) et celui qui contribue a Gnome pour la premiere fois a beaucoup moins de chance de se poser la question en rencontrant un char *, s'il ne se l'ai jamais posee auparavant.
> Il n'y a pas de structure de donnée liste de string en gtk+
> je vois pas trop l'intérêt par rapport à une glist à vrai dire...
J'en vois deux, voire trois:
- si une fonction prend en argument un glist, t'es oblige de lire la doc pour savoir c'est une glist de quoi, alors que si elle prend une gstringchunk, tu sais que c'est une liste de string
- pour optimiser la memoire
- il peut y avoir des fonctions interessantes a faire sur des listes de string mais pas ailleurs. Typiquement, dans Qt, les QStringList rajoutent quelques methodes par rapport aux QList: join, split, sort et grep (http://doc.trolltech.com/3.3/qstringlist.html(...))
> Enfin ton argument sur le coût de conversion est un peu fallacieux, j'ai beau chercher, je ne vois pas tant de fonction utiles
> qui prendraient ou renverraient des listes/hash tables de string... (à part des listes de tag dans GStreamer).
J'ai deux choses a repondre:
- pour gstreamer, c'est moins violent, mais le probleme se pose quand meme des la premiere string que tu veux echanger entre kde et gstreamer: un nom de fichier, un tag, le chemin dans le filesystem (qui peut comporter des accents, ...), un titre de chanson, une liste de chapitres. Rien que le fait de devoir utiliser glib, psychologiquement, ca passe mal. Je t'epargne mon opinion sur le travail d'optimiation qui peut etre effecte par le compilateur dans le cas ou il connait le type des donnes qu'il manipule .
- pour d'autres programmes, ca peut vite devenir genant. Citons la lib pour faire de la correction orthographique utilisee par abiword et koffice. T'imagines bien que les structures echangees vont etre assez complexe et vont devoir etre traduites a la volee
[^] # Re: ouah
Posté par Philippe F (site web personnel) . En réponse à la dépêche The aKademy 2004 a commencé. Évalué à 4.
A mon sens, le fait d'utiliser une structure speciale signale au developpeur qu'il peut y avoir des questions a se poser et lui font soulever plus vite la question de l'encodage utilise.
Tu peux te dire que le mec qui rencontre une gstring la premiere fois, il va aller voir la documentation et il va tomber sur le paragraphe qui dit que toutes les gstring sont codes en utf8 et va verifier qu'il n'a pas de problemes speciaux de conversion. Le mec qui rencontre un char * pour la premiere fois n'est pas pret de contribuer a Gnome (il a encore qqes mois devant lui) et celui qui contribue a Gnome pour la premiere fois a beaucoup moins de chance de se poser la question en rencontrant un char *, s'il ne se l'ai jamais posee auparavant.
> Il n'y a pas de structure de donnée liste de string en gtk+
Chuis pas trop d'accord:
http://developer.gnome.org/doc/API/2.0/glib/glib-String-Chunks.html(...)
> je vois pas trop l'intérêt par rapport à une glist à vrai dire...
J'en vois deux, voire trois:
- si une fonction prend en argument un glist, t'es oblige de lire la doc pour savoir c'est une glist de quoi, alors que si elle prend une gstringchunk, tu sais que c'est une liste de string
- pour optimiser la memoire
- il peut y avoir des fonctions interessantes a faire sur des listes de string mais pas ailleurs. Typiquement, dans Qt, les QStringList rajoutent quelques methodes par rapport aux QList: join, split, sort et grep (http://doc.trolltech.com/3.3/qstringlist.html(...))
> Enfin ton argument sur le coût de conversion est un peu fallacieux, j'ai beau chercher, je ne vois pas tant de fonction utiles
> qui prendraient ou renverraient des listes/hash tables de string... (à part des listes de tag dans GStreamer).
J'ai deux choses a repondre:
- pour gstreamer, c'est moins violent, mais le probleme se pose quand meme des la premiere string que tu veux echanger entre kde et gstreamer: un nom de fichier, un tag, le chemin dans le filesystem (qui peut comporter des accents, ...), un titre de chanson, une liste de chapitres. Rien que le fait de devoir utiliser glib, psychologiquement, ca passe mal. Je t'epargne mon opinion sur le travail d'optimiation qui peut etre effecte par le compilateur dans le cas ou il connait le type des donnes qu'il manipule .
- pour d'autres programmes, ca peut vite devenir genant. Citons la lib pour faire de la correction orthographique utilisee par abiword et koffice. T'imagines bien que les structures echangees vont etre assez complexe et vont devoir etre traduites a la volee