> 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.
Ben non. La derivation a deja ete faite en C++ (donc deja optimisee). Ensuite, la classe est visible dans ton langage cible. Si ce langage supporte la derivation, la derivation sera faite dans ce langage cible. La couche c ne sert vraiment qu'a transferer des appels.
Cela dit, tu as probablement raison que le plus lent, dans tout ca, c'est le langage cible. Sauf si ce n'est pas un langage de script : ada, ocaml, objective C.
> le C est nécessaire, et KDE devrait proposer des API sous cette forme,
Ben non, on est pas maso. Si tu veux faire des applis C graphiques, va voir Gnome, tu seras plus heureux. Les devs de KDE ont des criteres de qualite pour la facilite de developpement que le C ne remplit pas, et encore moins du C wrappant du C++. Ca a ete fait a une epoque et c'etait immonde.
Je pense qu'il est possible de voir l'avantage de programmer dans un langage objet lorsque tu manipules des concepts objets a tour de bras. Quitte a faire un binding aussi debile, je preferai le faire pour le brainfuck (http://www.muppetlabs.com/~breadbox/bf/).(...) Au moins, je sais pourquoi je le fais.
> Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.
Pourquoi est-ce que j'ai l'impression de me repeter 23 fois ? Ton argument est completement ecule. D'une part, il semble avoir ete exprime ici clairement que le C est loin de faciliter la vie des binder non plus pour d'autres raisons. D'autres part, KDE a resolue ce probleme du C++ en generant automatiquement une couche intermediaire en C extraite automatiquement des headers KDE.
Donc KDE facilite la vie des binders sur deux plans, et ce depuis 2002:
- la generation des api KDE dans un langage intermediaire est automatisee et maintenue a chaque version de KDE : pas besoin aux binders de maintenir cette partie la
- ils doivent uniquement s'occuper de la semantique du langage qu'ils binde, sachant que smoke prevoit deja toutes les caracteristiques des langages de scripts actuels : introspection et typage dynamique notamment.
[^] # 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é à 3.
> quand le langage de haut niveau cherchera à dériver le code C++ : il sera bien enmerder pour optimiser.
Ben non. La derivation a deja ete faite en C++ (donc deja optimisee). Ensuite, la classe est visible dans ton langage cible. Si ce langage supporte la derivation, la derivation sera faite dans ce langage cible. La couche c ne sert vraiment qu'a transferer des appels.
Cela dit, tu as probablement raison que le plus lent, dans tout ca, c'est le langage cible. Sauf si ce n'est pas un langage de script : ada, ocaml, objective C.
> le C est nécessaire, et KDE devrait proposer des API sous cette forme,
Ben non, on est pas maso. Si tu veux faire des applis C graphiques, va voir Gnome, tu seras plus heureux. Les devs de KDE ont des criteres de qualite pour la facilite de developpement que le C ne remplit pas, et encore moins du C wrappant du C++. Ca a ete fait a une epoque et c'etait immonde.
Je pense qu'il est possible de voir l'avantage de programmer dans un langage objet lorsque tu manipules des concepts objets a tour de bras. Quitte a faire un binding aussi debile, je preferai le faire pour le brainfuck (http://www.muppetlabs.com/~breadbox/bf/).(...) Au moins, je sais pourquoi je le fais.
> Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.
Pourquoi est-ce que j'ai l'impression de me repeter 23 fois ? Ton argument est completement ecule. D'une part, il semble avoir ete exprime ici clairement que le C est loin de faciliter la vie des binder non plus pour d'autres raisons. D'autres part, KDE a resolue ce probleme du C++ en generant automatiquement une couche intermediaire en C extraite automatiquement des headers KDE.
Donc KDE facilite la vie des binders sur deux plans, et ce depuis 2002:
- la generation des api KDE dans un langage intermediaire est automatisee et maintenue a chaque version de KDE : pas besoin aux binders de maintenir cette partie la
- ils doivent uniquement s'occuper de la semantique du langage qu'ils binde, sachant que smoke prevoit deja toutes les caracteristiques des langages de scripts actuels : introspection et typage dynamique notamment.