Discussion :

[dourouc05]

La dernière version de maintenance de Qt 4.8 est sortie, numérotée 4.8.7. Qt 5.0.0 est sorti fin 2012 ; l’un des objectifs était de garder une grande rétrocompatibilité avec les versions précédentes, pour faciliter la transition.

Cependant, certains développeurs ont préféré effectuer des changements plus profonds dans Qt 4.8, notamment afin d’exploiter les templates C++ et les nouveautés de la norme C++11. Leur travail a donné naissance à CopperSpice, dérivé de Qt 4.8. L’un des points essentiels est la disparition du moc, le compilateur de métaobjets utilisé par Qt depuis ses débuts. Ce générateur de code servait, dans les années 1990, à pallier les manques du C++ à l’époque, qui rendait impossible l’implémentation de systèmes comme les signaux et slots (également implémentés dans Boost.Signals dès le début des années 2000, sans tel outil).

Ce n’est pas la première fois que l’obsolescence de cet outil était pointée du doigt, malgré les justifications apportées dans la documentation. L’un des défauts couramment rapportés est l’impossibilité d’utiliser les templates avec ce système de métaobjets, mais également la performance (comparaisons de chaînes de caractères à l’exécution) — CopperSpice cite d’ailleurs dans sa documentation une liste d’inconvénients. Récemment, des preuves de concept ou des réflexions avancées ont été proposées pour s’en passer ou l’inclure au niveau du compilateur.

CopperSpice se défait donc complètement de cet héritage du passé, remplacé par C++11. Par conséquent, du code utilisant CopperSpice n’a pas besoin d’outil externe pour sa compilation, ce qui pouvait rendre les choses plus compliquées pour l’intégration avec du code C++ existant ; le code C++ utilisant Qt peut être transformé à l’aide d’un outil automatique de traduction, baptisé PepperMill. Il intègre également des nouveautés de Qt 5. De même, la compilation se fait avec les GNU AutoTools, certes plus répandus que qmake, mais pas forcément plus modernes (contrairement à CMake, par exemple). L’un des objectifs à plus long terme est de remplacer les conteneurs de Qt par leurs équivalents de la STL (ce qui évite de les recoder).

Cette manière de procéder pose cependant question : était-il nécessaire de créer un nouveau projet pour « juste » se débarrasser du moc, c’est-à-dire s’écarter d’une grande communauté ? Pourquoi repartir d’une version aussi ancienne (Qt 4.8.2 date de mai 2012), alors que Qt 5 a justement permis beaucoup de nettoyage ? Les développeurs de CopperSpice ont aussi leur propre version de Doxygen pour la documentation (renommée DoxyPress). L’univers Qt Quick ne fait pas partie des fonctionnalités de CopperSpice.

Sources : annonce de CopperSpice, site officiel, discussion sur Phoronix.
Billet original.

[RapotOR]

Quelqu'un a-t-il un retour positif sur CopperSpice avec un projet réel?

Personnellement, cela me semble fou de se baser sur une telle librairie. Cela sent le non-support dans X années.
Pourquoi ne pas avoir tenter d’intégrer leurs idées dans le projet original et faire profiter une plus grande communauté?

[Jbx 2.0b]

Assez d'accord avec RapotOR. On est déjà à Qt 5.5, avec des avancées significatives depuis Qt 4.8 (rien que le support des plateformes mobiles!) , et déjà presque 3 ans de développement. Pourquoi revenir en arrière ?
Le moc on est tous d'accord pour s'en passer, mais au final, c'est pas la mort non plus. Ça justifie pas un fork à mes yeux en tout cas, et encore moins le passage de projet (pro ou pas) vers un framework pas du tout officiel.
Qt c'est quand même 20 ans de loyaux services, et l'avenir semble radieux là ou beaucoup d'autres ont échoués.
Et je suis sur qu'il finira bien par abandonner son moc et switcher vers un C++ 11/14... Peut-être pour Qt 6.0 ?

[Markand]

Du site officiel :

The CopperSpice libraries were built using GNU Autotools

Faire un nouveau projet utilisant un langage moderne avec des outils obsolètes... C'est contradictoire. En plus Qt est très proche de CMake, c'est vraiment n'importe quoi.

[Uther]

L'idée de se débarrasser de cette horreur de moc est très bonne. Le soucis, c'est que c'est les gens de Qt qui devraient faire ça, pas un fork. Je ne comprend pas pourquoi ça n'a pas été fait lors du passage a Qt5, pour le coup, ça aurait vraiment justifié le changement de numéro de version majeure.

[dourouc05]

En 2011, Thiago Macieira a développé les raisons qui ont poussé à garder le moc bien vivant : http://www.macieira.org/blog/2011/09/the-future-of-moc/. Les raisons comptent notamment la compatibilité au niveau des sources avec Qt 4 (il faudrait voir à quel point PepperMill transforme le code pour le rendre compatible avec CopperSpice), les besoins d'introspection et les fonctionnalités dynamiques comme le chargement d'extensions.

[Uther]

Pour les plugins et l'introspection, je m'en passe très bien. Si on pouvait éviter d'avoir a utiliser Moc dans 95% des cas, ça serait déjà pas mal.

Pour l'introspection, je dirais même que je serais heureux si elle disparaissait. C'est une des fonctionnalités que j’exècre le plus dans les langages modernes.

[air-dex]

Assez d'accord avec RapotOR. On est déjà à Qt 5.5, avec des avancées significatives depuis Qt 4.8 (rien que le support des plateformes mobiles!) , et déjà presque 3 ans de développement. Pourquoi revenir en arrière ?

+1. Qt 4 appartient au passé désormais. Pourquoi vouloir persister dessus et refuser de passer à Qt 5 ?

(rien que le support des plateformes mobiles!)

Il vaudrait mieux dire "support officiel des plate-formes mobiles non Nokia". Symbian, Maemo et MeeGo utilisaient Qt 4(.7) quand ils étaient encore en vie. Il y avait également un projet officieux (Necessitas ou un nom dans ce genre) visant à porter Qt 4 sur Android.

[koala01]

Salut,

Du site officiel :



Faire un nouveau projet utilisant un langage moderne avec des outils obsolètes... C'est contradictoire. En plus Qt est très proche de CMake, c'est vraiment n'importe quoi.

Heuu, pourrais tu expliciter ton point de vue

Bien sur, il n'y a pas de jolie interface à la CMake, avec les autotools, mais, si tu y regardes d'un peu plus près (et quand tu sais utiliser ces outils), je peux t'assurer que le trio autocon / automake / libtool a encore de belles journées devant lui

A titre personnel, je sais être beaucoup plus efficace avec les auto-tools qu'avec Cmake, par exemple (mais bon, les gouts et les couleurs... hein )

Quelqu'un a-t-il un retour positif sur CopperSpice avec un projet réel?

Personnellement, cela me semble fou de se baser sur une telle librairie. Cela sent le non-support dans X années.
Pourquoi ne pas avoir tenter d’intégrer leurs idées dans le projet original et faire profiter une plus grande communauté?

L'idée de se débarrasser de cette horreur de moc est très bonne. Le soucis, c'est que c'est les gens de Qt qui devraient faire ça, pas un fork. Je ne comprend pas pourquoi ça n'a pas été fait lors du passage a Qt5, pour le coup, ça aurait vraiment justifié le changement de numéro de version majeure.

Savez vous qu'il y a cinq ans de cela, j'ai introduit une requete sur le bugtracker de... (qui c'était, encore, avant digia ) dont le but était de permettre une plus grande compatibilité entre QMap et std::map...

Ben oui, à l'époque (et, pour autant que je sache, à l'heure actuelle), QMap est limité à deux paramètres template (la clé et la valeur), alors que la std::map permet de préciser le comparateur à utiliser comme troisième paramètre.

Disons juste que, à l'époque, pour le projet (professionnel !!!) sur lequel je travaillais, cela nous aurais vachement aidé d'avoir cette compatibilité accrue . Mais, lorsque cette proposition a été évaluée, on m'a gentillement répondu "cela va casser la compatibilité binaire... peut être pour la version 5"

La version cinq est sortie depuis maintenant déjà pas mal de temps; et QMap n'est toujours pas compatible avec std::map...

Tout cela pour dire que, oui, bien sur, je regrette sans doute autant que vous qu'ils se soient basés sur une version "si ancienne" de la bibliothèque, mais, d'un autre coté, je ne peux m'empêcher de constater qu'il y a (ou qu'il y a eu) un tres fort immobilisme de la de la part des "maisons mères". Et je ne peux m'empêcher de penser qu'il fallait sans doute un fork pareil pour essayer de leur donner un bon coup de pied là ou le corps rejoint la chaise

Et puis, pensons positif... Cela incitera peut-être la maison mère à bouger un tout petit peu