Non, ce n'est pas du tout hors sujet :-)
Effectivement, on peut se poser la question. C'est à lui de voir. Mais la Glib introduit beaucoup d'autres choses utiles (listes chainées, tableaux dynamiques, traitement de chaines de caractères, opérateurs d'allocation mémoire rapides - http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slic(...) le tout portable sur un grand nombre de plateformes.
Voir la liste complète: http://developer.gnome.org/doc/API/2.0/glib/index.html
Résultat, si tu veux éviter des dépendances à plein de petites libs, c'est pas mal, et le code est plus uniforme et portable. L'API est très claire, donc facile à mémoriser, et orientée objet.
De plus, glib n'est pas indissociable de gtk: une appli gtk utilisera la glib, mais l'inverse n'est pas forcément vrai. Je code actuellement une application qui dépend de glib, mais comme elle n'est pas graphique je n'utilise pas gtk. Par contre, je ne passe pas mon temps à réinventer la roue.
[^] # Re: T'as du bol
Posté par liberforce (site web personnel, Mastodon) . En réponse au message parser un fichier de config. Évalué à 4.
Effectivement, on peut se poser la question. C'est à lui de voir. Mais la Glib introduit beaucoup d'autres choses utiles (listes chainées, tableaux dynamiques, traitement de chaines de caractères, opérateurs d'allocation mémoire rapides - http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Slic(...) le tout portable sur un grand nombre de plateformes.
Voir la liste complète: http://developer.gnome.org/doc/API/2.0/glib/index.html
Résultat, si tu veux éviter des dépendances à plein de petites libs, c'est pas mal, et le code est plus uniforme et portable. L'API est très claire, donc facile à mémoriser, et orientée objet.
De plus, glib n'est pas indissociable de gtk: une appli gtk utilisera la glib, mais l'inverse n'est pas forcément vrai. Je code actuellement une application qui dépend de glib, mais comme elle n'est pas graphique je n'utilise pas gtk. Par contre, je ne passe pas mon temps à réinventer la roue.