Avec ta couche supérieur en C par dessus le C++ le compilateur aura les même problèmes quand le langage de haut niveau cherchera à dériver le code C++ : il sera bien enmerder pour optimiser.
mais bon franchement on s'en balance des différences de perfs entre C++ et C objet, même si elles existent, le principal problème viendra de toute façon du binding dans le langage de haut niveau, ce binding constituera la plus lente des couches intermédiaires, avec tous les problèmes de perf lié au marshaling.
Tout ce que je constate c'est qu'au final le C est nécessaire, et KDE devrait proposer des API sous cette forme, même s'ils veulent par derrière utiliser un API C++. Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.
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.
Le binding s'en fou, il expose les api tel quel, au programmeur d'appeler le gfree dans son langage de haut niveau si besoin est. Bref, pour faire un binding de base "idiot" les .h suffisent et c'est tout à fait automatique et fonctionnel. Par contre si on veut cacher certains aspects techniques (gestion mémoire) pour simplifier la vie du programmeur ou faciliter l'intégration dans un langage de haut niveau, là oui il faut plus d'info. Mais ca c'est ce que j'ai déjà dis.
[^] # Re: Gnome, toujours trois trains de retard
Posté par TImaniac (site web personnel) . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 1.
mais bon franchement on s'en balance des différences de perfs entre C++ et C objet, même si elles existent, le principal problème viendra de toute façon du binding dans le langage de haut niveau, ce binding constituera la plus lente des couches intermédiaires, avec tous les problèmes de perf lié au marshaling.
Tout ce que je constate c'est qu'au final le C est nécessaire, et KDE devrait proposer des API sous cette forme, même s'ils veulent par derrière utiliser un API C++. Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.
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.
Le binding s'en fou, il expose les api tel quel, au programmeur d'appeler le gfree dans son langage de haut niveau si besoin est. Bref, pour faire un binding de base "idiot" les .h suffisent et c'est tout à fait automatique et fonctionnel. Par contre si on veut cacher certains aspects techniques (gestion mémoire) pour simplifier la vie du programmeur ou faciliter l'intégration dans un langage de haut niveau, là oui il faut plus d'info. Mais ca c'est ce que j'ai déjà dis.