Nouveau projet : Qt 4.8 ou Qt 5 ?

Bonjour

Je commence la réalisation d'un logiciel client - serveur. J'ai choisi d'utiliser C++ et Qt pour la développer. Je sais que Qt 5 est en phase de développement, et que pas mal de choses vont êtres modifiées par rapport à Qt 4.8.

Utiliser Qt 4.8 dans ce projet sachant qu'il sera dépassé dans pas longtemps me dérange. Par ailleurs, certaines fonctionnalités de Qt 5 me seraient bien utiles, comme par exemple le nouveau système signal/slot et le support natif du JSON pour mon protocole de communication entre le client et le serveur.

Je me posais donc la question : Est-ce que la bêta de Qt 5 est assez stable pour être utilisée en ce moment ? Est-ce que certains développeurs peuvent me donner leur retours sur cette bêta ?

Merci par avance

:salut:

Qt 5 finale est disponible dans pas trop longtemps, normalement, ça devrait donc le faire de l'utiliser dès maintenant. Au besoin, tu peux garder des sources compatibles avec les deux sans trop de problèmes (cf. Qt Creator).

Merci pour ton avis. Je pense que je vais tester l'utilisation de qt5 en espérant que la rc ne va pas tarder.

C'est moi ou Qt5 ne supporte pas VS2011? :?

La question n'est pas inversé ? "VS2011 ne supporte pas Qt 5 ?" non ? C'est au compilateur de supporter la lib, pas l'inverse

Si tu parles du plugin, il est possible que le plugin VS ne soit pas encore sorti. Mais je crois qu'ils ne sont pas encore là. Les dernières versions de Qt Creator que j'ai testé ne supporte pas encore Qt 5 (quand on fait "créer un nouveau projet", ça créé un projet Qt 4)

Quid du plug-in VS en version 1.2 ? http://origin.releases.qt-project.org/digia_vsaddin/ D'ailleurs, VS 2011... je veux bien, mais c'est quoi ? Tu veux parler de VS11, aussi appelé VS 2012, je suppose ?

Oups oui VS2012.

Citation:

---

La question n'est pas inversé ? "VS2011 ne supporte pas Qt 5 ?" non ? C'est au compilateur de supporter la lib, pas l'inverse

---

Oh que non. Qt fais partie de ces bibliothèques qui ne font pas que du C++ standard... d'ou le problème de compatibilité: la quasi totalité des bibliothèques que j'utilise sont compatible avec le compilateurs VC11 parceque les modification nécessaires pour ça étaient mineures. Avec Qt c'est souvent pas le cas. Ils ont mis énormément de temps à fournir des binaires pour VC10 (qui étaient longtemps fournis par de généreux bénévoles sur ces forums avant) et ils sont en train de faire la même chose encore. Et visiblement c'est le même souci avec les dernières versions de gcc avec C++11 activé.

C'est assez fatiguant parceuqe c'est la seule lib (je parles de QtCore et QtGUI essentiellement) que j'ia dans mes divers projets qui m'oblige a avoir le VC10 encore sur le disque.

Enfin bref.

Citation:

---

Envoyé par dourouc05

Quid du plug-in VS en version 1.2 ? http://origin.releases.qt-project.org/digia_vsaddin/ D'ailleurs, VS 2011... je veux bien, mais c'est quoi ? Tu veux parler de VS11, aussi appelé VS 2012, je suppose ?

---

Cool qu'il y ait le vsaddin opur vs2012 mais donc ça ne marche qu'avec VC10 ou bien ya les binaires de Qt5 VC11 planqués quelque part?

Ok, j'avais pas compris que tu parlais des binaires compilés avec VS 2012. Il n'y a pas une ABI commune entre les 2 ?
A priori, pour le moment, les tests sur Qt 5 beta sont fait uniquement avec VS 2010 (http://qt-project.org/doc/qt-5.0/pla...s-windows.html)
Probablement que dans la version finale, il y aura 2012 (faut juste ajouter la chaîne de compilation dans le système IC de Qt, ça devrait pas être difficile)

C'est ce que je me disais sur la version finale de qt 4.5 (je crois) mais au final ils l'on sorti avec les même compilo et sans VS2010.

Bref je viens de tester le VS Addin 1.2, il colle au reste: uniquement vs2010.

C'est vieux Qt 4.5. Depuis il y a l'open gouvernance et l'utilisation de l'intégration continue pour la compilation. Tu dois pas être le seul, j'imagine que d'autre ajouteront VS2012. A voir

Oui visiblement cerains arrivent a le compiler, mais c'est juste la distribution de base qui est un peu desesperante parcequ'elle a beaucoup d'inertie par rapport a l'évolution de l'environnement C++.

M'enfin bon j'imagine que ça sera réglé dans quelques mois ;__;

Citation:

---

Envoyé par Klaim

Oui visiblement cerains arrivent a le compiler, mais c'est juste la distribution de base qui est un peu desesperante parcequ'elle a beaucoup d'inertie par rapport a l'évolution de l'environnement C++.

---

Ce qui me désespère pour ma part, c'est le merdier qui règne dans la compilation en C++...

Citation:

---

Envoyé par bretus

Ce qui me désespère pour ma part, c'est le merdier qui règne dans la compilation en C++...

---

On est un peu HS, mais tu peux expliquer ?

Citation:

---

Envoyé par gbdivers

On est un peu HS, mais tu peux expliquer ?

---

Tu prends une bibliothèque écrite en C++, à défaut de compatibilité binaire tu ne disposes même pas d'un mécanisme standard pour la compiler avec des options par défaut pour ton compilateur.

En l'absence de mécanismes standards de paramétrage des compilations, de génération de code (version des dépendances) et de recherche des dépendances : Il règne un folklore monstrueux qui un véritable frein à la réutilisation des bibliothèques.

Quand tu trouves la réponse à tes besoins dans un framework tel Qt ou Boost qui apporte une couche d'homogénéisation, tout va bien. Dès que tu as des besoins spécifiques et que les bibliothèques qui y répondent n'y sont pas présentes, tu peux ramer comme une bête pour les intégrer.

Quand tu te places du côté du fournisseur de bibliothèque, si tu te contentes de fournir quelque chose qui produit un .lib ou un .a, l'utilisateur ramera pour gérer la version de ta bibliothèque et l'intégrer dans sa chaîne de compilation.

La question qui devrait se poser est : Qu'est-ce qui manque autour de C/C++ pour qu'on ait besoin de qmake, cmake, bjam, etc.?

Avec des conventions en C++ et quelques outils standards, on pourrait se rapprocher de prend le ".jar" met le dans "lib", sinon prend les sources et met les dans src, et code ma poule.

Libre à ceux qui veulent des options de compilation avancées de s'en passer... En l'état, il est regrettable de voir des personnes expérimentées dans le langage ramer pour compiler des bibliothèques en raison de chaînes de compilation spécifiques à un framework ou à des systèmes (autotools)

Ok merci

Je dois avouer n'avoir jamais trop eu de problème pour utiliser des libs. C'est peut être une question de domaine
J'utilise qmake et cmake, mais surtout pour l'intégration continue (gérer les compilation multi plateforme, les tests, générer les paquets). J'ai l'impression que c'est beaucoup du "si les binaires existent, je link les dll/so, sinon j'inclue les sources dans le projet"

Mais il est vrai que je suis parfois faignant et je préfère utiliser les binaires s'ils existent plutôt q'une version plus récente (par exemple j’utilise boost 1.50 sur ubuntu qui est fournit dans les paquets plutôt que compiler la dernière version 1.51)
Par contre, s'il une nouvelle version m'intéresse (Qt 5 avant que les binaires sortent par exemple), j'hésite pas à intégrer dans la compilation. Même les libs qui ont un système de compilation différents me semblent pas trop poser de problème (c'est souvent "copier coller les lignes de commandes données dans le INSTALL")

Je suis globalement d'accord avec bretus et j'ai souvent eu cette reflexion au cours de ces dernières années.

En fait ça dépends de quel projet, spécifiquement, tu fais, parceque ça dépends de tout ce qui est dépendances.

Par exemple, j'ai bossé sur un projet ou tout devait être open source et avec les sources, et compilable avec gcc4.4. Le tout basé sur Scons. Qu'est-ce qu'ils se passe quand tu dois ajouter une dépendence (comme c'était mon cas) qui n'a rien pour marcher de base avec scons? Ben tu dois faire un peu de dev (qui avec un peu de chances sera toujours valide si tu update ta dépendence...avec de la chance hein) et faire une surcouche de python pour que tout le projet soit un tout cohérent.

Je bosse actuellement sur un jeu qui a pas mal de dépendances. J'ai choisi CMake mais j'aurais préféré un truc plus idéal. CMake m'apparait toujours comme un aglomérat de fonctions de bricolage. Bref, la moitié de mes libs sont sous CMake, ce qui m'avantage pour les ajouter dans le projet. Mais pour le reste? Des hacks, parfois platform-specific, essentiellement parceque les devs ne sont pas d'accord pour fournir un CMake officiel des sources.
Oui parceque je préfère largement avoir les sources dispo de mes libs, tout simplement parceque je suis tombé parfois sur des problèmes que je pouvais résoudre moi-même, sans avoir a attendre une update des developeurs. J'ai une grosse couche de CMake pour unifier l'ensemble de mes dépendences comme je veux et par dessus j'ai encore du Python.
Avec ce projet, comme je compile moi même les dépendences (boost inclus, mais compilé une fois pour touts les projets), je peu bosser sur n'importe quel compilo/IDE que CMake gère. Mais j'ai mis plusieurs mois à mettre en place ce satané écosysteme, juste parceque j'ai différentes dépendances.

J'ai un autre projet, open source cette fois, qui utilise qt. Je suis parti sur du CMake, ce qui m'arrange pour par exemple pouvoir intégrer Qt. Par contre tant que Qt n'est pas dispo pour certains compilateurs, je devrias le compiler moi même ce qui non seulement a des chances d'échouer (essentiellement a cause de qmake et d'autres subtilités de dépendences de Qt) mais en plus ça me prendrais carrément plus de temps que de compiler boost (ce qui est une sacrée performance). Ne me parlez même pas de QtCreator, je n'ai pas réussi a l'utiliser avec mon projet. J'espère toujours qu'un expert Qt m'aiderai sur ce point mais c'est peine perdue, il faudrait que QtCreator soit distribué avec un compilateur qui accepte les lambda par exemple... (que j'utilise)

Bref, l'absence de norme pour tout ce qui est dépendences (quelle que soit sa forme) est une vrai plaie, effectivement. C'est encore enpiré par le fait que les dévelopeurs d'IDE ne peuvent pas vraiment bosser sur un format qui marche de manière cross-platform. Du coup ils essaient de bosser avec CMake ou autre, mais vainement parcequ'ils ne sont pas pensé pour l'intégration dans un IDE. Pire: ils ne font rien pour aider quoi que ce soit quand il sagit de cross-platform, comme poru Visual Studio.

Donc franchement c'est la grosse merde et ça fais perdre un temps fou, ou on est même pas encore sur des problèmes de code ou d'architecture.

Ca me déprime. :cry:

Ok

J'utilise cmake aussi. Par contre, si une lib n'utlise pas cmake, je m'embête pas à la compiler avec cmake, je lancer juste le script de compilation puis j'intègre dans cmake

Pour QtCreator, tu peux appeler n'importe quelle chaîne de compilation dessus. Perso j'utilise gcc 4.8 avec (donc pas de problème pour les lambdas)

Citation:

---

Envoyé par gbdivers

J'utilise cmake aussi. Par contre, si une lib n'utlise pas cmake, je m'embête pas à la compiler avec cmake, je lancer juste le script de compilation puis j'intègre dans cmake

---

Ça marche bien quand on peut exécuter le script... Quand un utilisateur de Visual Studio vient te demander comment il compile ta bibliothèque, tu ne peux pas lui dire : Lance d'abord le "configure" de ma dépendance mon finder cmake se chargera du reste.

Ton utilisateur dois se frapper la compilation de la bibliothèque, déchiffrer le processus de compilation, comprendre là où le type fait des "sed", quelles sont les variables de préprocesseur qu'il doit définir, etc.

Même si le code de ta dépendance est portable, son processus de compilation ne l'est pas.