<< Yahoo. Donc tu proposes de mettre une couche C à KDE. Clap clap clap. Tu dis que en c++ c ouachement mieux parcque c optimisé par rapport à C machin machin, et tu proposes de justement de rajouter une couche qui, si on te suit, n'est pas optimisé puisqu'en C. Cherche l'erreur.
>>
Tu peux essayer de tourner la phrase pour que ce que je dise paraisse debile mais je maintiens.
Tu as plusieurs niveaux:
- Gtk (avant gobject), avec un framework objet emule en C, et eventuellement un binding genere a la main. Le compilateur ne peut pas optimiser correctement les parties objet du code car il ne connait pas l'objet. Les bindings attaquent directement les .h de gtk (bien que ce point soit a verifier, je ne serait pas surpris qu'il y aie des couches intermediaires, par exemple pour gerer le comptage de reference et autres joyeusetes des langages de script).
- KDE, avec un framework en C++, que le compilateur peut optimiser correctement. Ce framework genere ensuite une _interface_ en C, qui utilise en interne du C++ (qui est donc optimisee correctement par le compilateur), mais qui ajoute au moins un appel de fonction par methode. Pour info, le cout d'un appel de fonction de nos jours et negligeable, plus particulierement dans un gui ou c'est l'utilisateur qui declenche les evenements.
- Gnome + Gobject : le framework objet s'est complexifie, mais est toujours en C (donc toujours aussi difficile a optimiser) mais en plus, on genere une couche intermediaire qui sert a interfacer le binding. Bref, on cumule deux inconvenients en terme de performance, mais on gagne en qualite des bindings et en quantite de travail.
Il serait interessant de valider ce que j'affirme avec des benchs. Je serai infiniment surpris si l'appel d'une methode virtuelle en gobject etait plus rapide qu'en C++. J'essaye d'imaginer le nombre d'etape intermediaire par lequel le code C passe pour simuler une methode virtuelle.
> Si tu veux te contenter d'appeler les API à la mode C, t'as toutes les infos nécessaire dans le .h
- g_strstr() renvoie un gchar * deja alloue a ne pas liberer.
- g_strdup_printf() renvoie un char * qui doit etre libere.
Dis moi comment un binding base sur une moulinette du .h peut savoir si il doit faire des gfree sur les chaines renvoyees par ces fonctions. Tu es oblige d'inclure une phase manuelle basee sur la documentation que tu auras lu.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Philippe F (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 5.
>>
Tu peux essayer de tourner la phrase pour que ce que je dise paraisse debile mais je maintiens.
Tu as plusieurs niveaux:
- Gtk (avant gobject), avec un framework objet emule en C, et eventuellement un binding genere a la main. Le compilateur ne peut pas optimiser correctement les parties objet du code car il ne connait pas l'objet. Les bindings attaquent directement les .h de gtk (bien que ce point soit a verifier, je ne serait pas surpris qu'il y aie des couches intermediaires, par exemple pour gerer le comptage de reference et autres joyeusetes des langages de script).
- KDE, avec un framework en C++, que le compilateur peut optimiser correctement. Ce framework genere ensuite une _interface_ en C, qui utilise en interne du C++ (qui est donc optimisee correctement par le compilateur), mais qui ajoute au moins un appel de fonction par methode. Pour info, le cout d'un appel de fonction de nos jours et negligeable, plus particulierement dans un gui ou c'est l'utilisateur qui declenche les evenements.
- Gnome + Gobject : le framework objet s'est complexifie, mais est toujours en C (donc toujours aussi difficile a optimiser) mais en plus, on genere une couche intermediaire qui sert a interfacer le binding. Bref, on cumule deux inconvenients en terme de performance, mais on gagne en qualite des bindings et en quantite de travail.
Il serait interessant de valider ce que j'affirme avec des benchs. Je serai infiniment surpris si l'appel d'une methode virtuelle en gobject etait plus rapide qu'en C++. J'essaye d'imaginer le nombre d'etape intermediaire par lequel le code C passe pour simuler une methode virtuelle.
> Si tu veux te contenter d'appeler les API à la mode C, t'as toutes les infos nécessaire dans le .h
Ok, je prends deux fonctions au hasard:
cf http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Fun(...)
- g_strstr() renvoie un gchar * deja alloue a ne pas liberer.
- g_strdup_printf() renvoie un char * qui doit etre libere.
Dis moi comment un binding base sur une moulinette du .h peut savoir si il doit faire des gfree sur les chaines renvoyees par ces fonctions. Tu es oblige d'inclure une phase manuelle basee sur la documentation que tu auras lu.