J'avais discuté du sujet avec plusieurs personnes pointues sur le sujet (notamment le mainteneur du binding gtkmm (gtk pour C++).
Faire des bindings pour une lib en C est très facile d'approche. Il n'y a peu de difficultés techniques (d'apparence en tout cas) et c'est un très bon projet libre pour se mettre dans le bain. C'est pour ça qu'on en trouve autant.
Faire des bindings pour une lib en C++ est beaucoup plus difficile à réaliser d'entrée de jeu. On se trouve immédiatement confronté à de grosses difficulté. En effet, tous les bindings vers d'autres langages fonctionnent à partir du C (en tout cas, ceux que j'ai vu). Il faut donc faire une grosse couche de C, et ensuite, dans le langage cible, il faut quand même reconstituer l'interface objet pour que ca ressemble à l'original. Assez fastidieux. Il me semble aussi que le passage de référence est plus complexe en C++ qu'en C. Il faut aussi surcharger d'emblées toutes les méthodes virtuelles pour les fournir dans le langage cible, etc etc.
Le C part donc avec un gros avantage au départ ... mais seulement au départ. En effet, l'approche des bindings en C suppose une très grosse part de travail manuel pour analyer les structures fournies par Gtk et en faires des objets cohérents dans le langage cible. C'est le problème inhérent de Gtk: la couche objet n'est pas "native" en C, et doit donc être reconstruite à la main.
C'est pour ça que les bindings en C ont très souvent (ou en tout cas avaient très souvent) une voire plusieurs release de retard: il y a un gros effort qui est fourni à un moment donné pour avoir une version stable, mais intégrer les nouvelles versions quand elles sortent représente un travail massif qui dépasse sur la durée la capacité des contributeurs les plus motivés (c'était comme ça il y a 10 ans en tout cas).
Le C++, au contraire se prête assez bien à une génération automatique. Parser un header C++ apporte presque toutes les informations nécessaire à la création du binding. Il faut quand même complémenter quelques informations (la gestion de propriété des pointeurs par exemple). Mais sur la durée, ca tient mieux la route: une fois la grosse machinerie initiale mise en place, mettre à jour pour des nouvelles classes ou une nouvelle version demande un travail manuel beaucoup plus limité.
Voici ce qu'en disent les pages sur les deux outils majeurs pour cette tâche:
SIP comprises a code generator and a Python module. The code generator processes a set of specification files and generates C or C++ code which is then compiled to create the bindings extension module. The SIP Python module provides support functions to the automatically generated code.
The specification files contains a description of the interface of the C or C++ library, i.e. the classes, methods, functions and variables. The format of a specification file is almost identical to a C or C++ header file, so much so that the easiest way of creating a specification file is to edit the corresponding header file.
To generate SMOKE libs for your own libs and APIs, a new tool has been written, called 'smokegen' [...]. smokegen itself only does the parsing of C++ header files [...]
Côté KDE, l'infatigable Richard Dale a travaillé avec David Faure sur Smoke pour faire des bindings pour Perl, Php, Ruby et C# si je me souviens bien. Aucun n'a pris non pas parce qu'ils sont mauvais, mais parce qu'il n'y a peu d'intérêt (voire aucun) à avoir Qt pour ces langages. Les programmeurs Qt se satisfont globalement très bien de C++, ceux qui trouvent ça trop lourd se satisfont de Python ou partent rapidement vers Gtk et WxWidget.
Un autre aspect est que pour une lib comme Gtk, le C reste assez lourd à manipuler. Des langages comme Python, Vala, C# ou autres apportent un réel plus en terme de simplicité du code à manipuler et de programmation objet. Qt ne souffre pas du même défaut, les concepts sont très bien exprimés en C++ (voire représentent une simplificaiton du C++, cf mon post plus bas) et la motivation pour écrire dans un langage annexe est beaucoup moins forte.
Pour terminer sur les bindings C difficiles à générer, la situation n'a pas échappé aux mainteneurs côté Gtk. Lassés de faire un gros travail à la main à chaque release, ils ont planché sur une amélioration de GObject, pour fournir de base suffisamment d'information pour automatiser la génération: c'est l'introspection GObject . Si j'en crois la page de bindings de Gtk, le travail a l'air d'avoir payé puisque les bindings vers les langages majeurs sont bien à jour.
Allez, pour finir, un petit troll: en dehors des développeurs de Mandrake, quelqu'un connait des (削除) malades (削除ここまで) développeurs que utilisent PerlGtk ?
[^] # Re: Uchronie
Posté par Philippe F (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 10.
J'avais discuté du sujet avec plusieurs personnes pointues sur le sujet (notamment le mainteneur du binding gtkmm (gtk pour C++).
Faire des bindings pour une lib en C est très facile d'approche. Il n'y a peu de difficultés techniques (d'apparence en tout cas) et c'est un très bon projet libre pour se mettre dans le bain. C'est pour ça qu'on en trouve autant.
Faire des bindings pour une lib en C++ est beaucoup plus difficile à réaliser d'entrée de jeu. On se trouve immédiatement confronté à de grosses difficulté. En effet, tous les bindings vers d'autres langages fonctionnent à partir du C (en tout cas, ceux que j'ai vu). Il faut donc faire une grosse couche de C, et ensuite, dans le langage cible, il faut quand même reconstituer l'interface objet pour que ca ressemble à l'original. Assez fastidieux. Il me semble aussi que le passage de référence est plus complexe en C++ qu'en C. Il faut aussi surcharger d'emblées toutes les méthodes virtuelles pour les fournir dans le langage cible, etc etc.
Le C part donc avec un gros avantage au départ ... mais seulement au départ. En effet, l'approche des bindings en C suppose une très grosse part de travail manuel pour analyer les structures fournies par Gtk et en faires des objets cohérents dans le langage cible. C'est le problème inhérent de Gtk: la couche objet n'est pas "native" en C, et doit donc être reconstruite à la main.
C'est pour ça que les bindings en C ont très souvent (ou en tout cas avaient très souvent) une voire plusieurs release de retard: il y a un gros effort qui est fourni à un moment donné pour avoir une version stable, mais intégrer les nouvelles versions quand elles sortent représente un travail massif qui dépasse sur la durée la capacité des contributeurs les plus motivés (c'était comme ça il y a 10 ans en tout cas).
Le C++, au contraire se prête assez bien à une génération automatique. Parser un header C++ apporte presque toutes les informations nécessaire à la création du binding. Il faut quand même complémenter quelques informations (la gestion de propriété des pointeurs par exemple). Mais sur la durée, ca tient mieux la route: une fois la grosse machinerie initiale mise en place, mettre à jour pour des nouvelles classes ou une nouvelle version demande un travail manuel beaucoup plus limité.
Voici ce qu'en disent les pages sur les deux outils majeurs pour cette tâche:
SIP
SIP comprises a code generator and a Python module. The code generator processes a set of specification files and generates C or C++ code which is then compiled to create the bindings extension module. The SIP Python module provides support functions to the automatically generated code.
The specification files contains a description of the interface of the C or C++ library, i.e. the classes, methods, functions and variables. The format of a specification file is almost identical to a C or C++ header file, so much so that the easiest way of creating a specification file is to edit the corresponding header file.
Smoke
To generate SMOKE libs for your own libs and APIs, a new tool has been written, called 'smokegen' [...]. smokegen itself only does the parsing of C++ header files [...]
Côté KDE, l'infatigable Richard Dale a travaillé avec David Faure sur Smoke pour faire des bindings pour Perl, Php, Ruby et C# si je me souviens bien. Aucun n'a pris non pas parce qu'ils sont mauvais, mais parce qu'il n'y a peu d'intérêt (voire aucun) à avoir Qt pour ces langages. Les programmeurs Qt se satisfont globalement très bien de C++, ceux qui trouvent ça trop lourd se satisfont de Python ou partent rapidement vers Gtk et WxWidget.
Un autre aspect est que pour une lib comme Gtk, le C reste assez lourd à manipuler. Des langages comme Python, Vala, C# ou autres apportent un réel plus en terme de simplicité du code à manipuler et de programmation objet. Qt ne souffre pas du même défaut, les concepts sont très bien exprimés en C++ (voire représentent une simplificaiton du C++, cf mon post plus bas) et la motivation pour écrire dans un langage annexe est beaucoup moins forte.
Pour terminer sur les bindings C difficiles à générer, la situation n'a pas échappé aux mainteneurs côté Gtk. Lassés de faire un gros travail à la main à chaque release, ils ont planché sur une amélioration de GObject, pour fournir de base suffisamment d'information pour automatiser la génération: c'est l'introspection GObject . Si j'en crois la page de bindings de Gtk, le travail a l'air d'avoir payé puisque les bindings vers les langages majeurs sont bien à jour.
Allez, pour finir, un petit troll: en dehors des développeurs de Mandrake, quelqu'un connait des
(削除) malades (削除ここまで)développeurs que utilisent PerlGtk ?