Discussion :

[Kadesh]

Bonjour à tous,

Je suis passionné par les interfaces interactives, je fais du design etc. mais je n'y connais pas grand chose en programmation.

J'ai commencé le c++ il y a un moment et j'ai bientot finit le chapitre traitant de la POO, et là j'arrive à QT. Je me demandais si c'était le choix le mieux adapter pour développer des applications desktop très poussé graphiquement?

En gros je veux transformer les interfaces figées effectuée via gimp en un programme qui réagit à l'utilisateur (avec des effets plus ou moins légers) et permet d'introduire du contenu, gérer des bases de données, du contenu web etc.

Que me conseillez vous?
Sachant que à terme je souhaite faire une application smartphone et un site web reliés au programme desktop ==> évidemment projet de plusieurs années, mais c'est pour le plaisir!
D'ailleurs j'ai failli choisir Java à cause de ça puisqu'il sert dans android/windows/web, mais j'ai douté de sa robustesse pour le desktop sachant que mes interfaces prendront dans une certaine mesure des ressources et que je voudrais vraiment optimiser l'utilisation de la mémoire avec c++ afin d'offrir aux utilisateurs une bonne expérience même avec un pc pourri, bon choix?

Merci,

Kadesh

[dragonjoker59]

Si tu veux des interfaces graphiques très poussées graphiquement, le C++ n'est selon moi pas le bon choix, en tout cas sous Windows.
Si tu le peux, passe en C# et utilise WPF qui va te permettre de faire des GUI poussées, avec des shaders et tout et tout...

EDIT :
Je n'avais pas lu tout ton message, dont la partie smartphone et web.
Pourquoi ne pas partir sur du développement web moderne ? (HTML5, CSS3)

[Kadesh]

dragonjoker59 >

Merci pour l'information, je ne savais pas que C# avait des fonctionnalités supérieures à celles du C++ concernant le graphisme, je pensais vraiment qu'avec C++ on pouvait tout faire sur desktop et c'est ça qui m'avait attiré. Ne puis-je pas arriver au même résultat graphique avec C++ sans trop me tordre le cerveau? Peut être y-a-t-il de nouvelles fonctionnalités avec C++11?

J'avais également été attiré par le fait que le C++ est tellement large niveau paradigmes qu'il permettait de passer à presque n'importe quel autre langage relativement facilement quand on a un besoin spécifique. Alors que le passage de C# vers C++ est plus compliqué n'est-ce pas?

Et je voulais également acquérir de bonnes habitudes en programmation, ai-je fait le mauvais choix?
Le C++ est-il limité à un domaine particulier de l'informatique?

Par ailleurs concernant le web, effectivement je comptais utiliser le couple html5 css3, mais ca ce sera plus tard, là je me concentre exclusivement sur une version desktop de mon programme, car je ne veux pas avoir de limitations graphiques, alors que sur navigateur malheureusement tu dois faire beaucoup de sacrifices à ce niveau sinon c'est ingérable.

J'attends avec impatience vos réponses

[dragonjoker59]

Ben en C++, théoriquement tu peux tout faire. Par contre, tu vas effectivement te tordre le cerveau pour avoir le résultat voulu (pour l'avoir fait, je te le confirme).
Ne connaissant pas Qt, je ne peux pas te dire ce qu'elle vaut au niveau personnalisation de ta GUI.
Par contre, pour faire de la GUI, C# est nettement plus approprié que le C++, qui n'intègre rien de base pour la gestion des GUI (d'où l'existence de bibliothèques telles que Qt et wxWidgets).

[ternel]

Bien sûr que C++ peut tout faire, GIMP est codé avec, justement.
Il suffit de savoir comment, et c'est là le problème.

Certains langages sont plus pratiques, car il y a ce qu'il faut de base.
Un autre exemple, c'est Java, avec Swing. C'est ainsi qu'est codé LibreOffice (et OpenOffice).

Avec les dernières normes HTML5 (et CSS3, son compagnon), tu peux faire énormément de choses avant de rencontrer les limites.

La question est de savoir ce que ton interface sert à faire.
Un jeu, avec beaucoup de données derrières, et du temps réel? reste sur le C++, ca me parait plus adapté (drivers opengl/directX)
Un programme à base de bouton, qui fait quasiment rien tant que l'utilisateur ne clique pas partout? (Traitement de texte, tableur, progiciel de comptabilité...) Java+Swing par exemple

Tu tiens à te limiter explicitement à windows? C# peut être considéré.

Tu veux pouvoir modifier le style selon l'utilisateur, il n'y a que peut de traitement, l'application pourrait avoir un usage sur tablette/téléphone? html+css est idéal.

N'hésite pas à nous en dire un peu plus, nous pourrons te conseiller un peu mieux.

[Kaamui]

Qt fait de très bonne choses également du point de vue des interfaces graphiques. Par exemple, un logiciel fait en C++ avec Qt : Open Sankoré

Donc continue ton apprentissage avec Qt et le C++, car si le C++ n'était pas bon en interface graphique, il n'y aurait pas autant d'applis et de jeux vidéos AAA faits en C++

le C# non plus n'intègre rien nativement pour les GUI, c'est le framework .Net (le Qt du C#) qui le fait.

[Kadesh]

Enfaite je suis intéressé par pleins de domaines en programmation et j'ai beaucoup de projets.
Par exemple l’intelligence artificielle, la gestion vidéo (ex movie maker avec des fonctionnalités supplémentaires), architecture etc.

Je pensais que débuter par C++ permettrait de faire de moi un excellent programmeur qui peut passer à n'importe quel langage en fonction de son projet.

Mon premier projet est un projet de traitement de l'information, de bases de données (infos contenus sur le pc, ou sur des serveurs, ou des navigateurs),
Il y aura plusieurs fenêtres redimensionnables au sein du logiciel qui permettent de comparer des données et d'en extraire les informations utiles.
Mais je veux que ce soit ergonomique, interactif et poussé graphiquement.

En gardant l'objectif de ce premier projet en tête, plus mon objectif d'avoir une excellente culture des différents paradigmes disponibles en programmation, Le C++ est-il un bon choix pour ce premier projet?

Je veux faire d'une pierre deux coups, commencer ce projet qui me motive ET acquérir une culture de programmeur en même temps.
Même si c'est raisonnablement plus galère de faire ce projet en C++ (j'imagine qu'il existe quand même une bibliothèque correcte pour la GUI non? J'ai cité QT mais il en existe peut être d'autres?)

Imaginons que je commence par Java ou C#, ne serais-je pas limité si plus tard j'ai besoin du C++?
J'ai souvent lu qu'il est plus long d'acquérir une bonne vision de programmeur dans ces langages relativement plus haut niveau et plus limités niveau paradigmes que C++, est-ce vrai?

J'ai lu ceci sur un forum :

Le C# et le Java ne se sont pas suffisamment détaché de leur modèle, le C++, pour justifier leur intérêt intrinsèque en tant que langage. Pire encore, ils sont tous les deux destinés à une mort inévitable, Microsoft va disparaître en emportant C# dans sa lente agonie, et la plate-forme Java devient de plus en plus ingérable, la machine virtuelle est déjà poussée à ses limites quand on veut certains concepts de programmation fonctionnelle qui seront essentiels dans l'avenir

J'ai également lu ceci

Le C# et le Java sont un peu dans le même bateau, ce sont deux langages assez semblables, créés en réaction à la complexité extravagante du C++, pour permettre à une masse de programmeurs bas de gamme de travailler sur des gros projets sans trop tout casser, en forçant partout des contraintes de programmation orienté objet dans des proportions malsaines et parfois comiques, et encourageant des "design patterns" qui dans leur majorité sont des béquilles pour compenser le manque de dynamisme du langage, la difficulté de manipuler les traitements comme des données, et les couplages introduits par l'utilisation déraisonnable de la relation d'héritage.

Programmer en C# ou en Java, c'est sortir des outils d'une boîte à outils géante, qui font à peu près ce qu'on veut faire mais pas tout à fait, et taper avec jusqu'à ce que ça rentre. On finit avec un programme qui fait à peu près ce qu'on veut faire, dont on prie que l'implémentation cachée derrière n niveaux d'abstractions et une hiérarchie de classes imbitable fonctionne correctement et soit adaptée à nos besoins, avec des performances acceptables et sans occuper toute la RAM.

Dans 99% des cas, le C# ou le Java permettent d'accomplir ce qu'on veut, avec une approche systématique pour ne pas dire ennuyeuse, sans trop se casser le cul.

Ces langages relèvent parfois davantage de l'outil de propagande corporatiste auprès d'une génération de programmeurs lobotomisés et consentants, que réellement de la programmation. Ce sont des langages efficaces, productifs, charmeurs, mais qui pouponnent les programmeurs pour en faire des esclaves de telle plate-forme propriétaire aux garanties de performance ou de sécurité parfois vagues.


___________

Adopter un langage de programmation copyrighté défini par une entreprise plutôt que par des comités internationaux indépendants, c'est aussi vendre son âme au diable en échange de confort, de facilité de déploiement ou de gestion de la médiocrité générale des programmeurs impliqués dans le projet. S'il s'agit de faire des logiciels pour gérer les factures pour le compte d'un grand groupe multinational dans une SSII, alors oui tu trouveras ces langages partout.

__________
Java tiendra plus longtemps que C# (quelques projets intéressants sont basés sur Java : Hadoop, Cassandra, le langage Scala) mais ils disparaîtront comme tendent à disparaître toutes les tentatives de les généraliser au-delà des contextes que l'entreprise qui les gère peut les supporter (Mono, implémentations alternatives de la jvm, etc.).

Il y aura une inertie d'au moins quinze ou vingt ans sur C# et Java, donc ce sont encore des alternatives très viables pour le moment, d'un point de vue purement "perspectives d'avenir pour des professionnels de l'informatique".

Bon je veux pas lancer une guerre, d'ailleurs je comprends pas la moitié de ce qui est écrit là dessus, mais ca ne donne pas envie...
Je suis vraiment un débutant complet qui prends du temps avant de se lancer corps et âme dans un premier langage (même si je commence tout doucement C++, car comme vous le voyez, je suis déjà pas mal influencé par ce que j'ai lu, ai-je tort ?)

[Ehonn]

Des projets comme VLC (lecteur multimédia) ou KDE (environnement de bureau) sont faits avec Qt.

[Kaamui]

Si tu veux faire des trucs assez bas-niveau (entends proche de la machine), il vaut mieux que tu t'orientes vers le C++, qui contrairement au C# par exemple, va te laisser gérer la mémoire utilisée par ton programme toi-même, te fournissant ainsi des notions indispensables pour la suite de ce que tu veux faire.

[Kadesh]

Si tu veux faire des trucs assez bas-niveau (entends proche de la machine), il vaut mieux que tu t'orientes vers le C++, qui contrairement au C# par exemple, va te laisser gérer la mémoire utilisée par ton programme toi-même, te fournissant ainsi des notions indispensables pour la suite de ce que tu veux faire.

Non pas spécialement bas niveau si ce n'est avec l'intelligence artificielle. Mais effectivement je veux optimiser la gestion de la mémoire pour permettre à tout le monde (même avec pc merdique) de bénéficier d'une super expérience graphique sans que ca rame.

Merci de me rassurer sur l'utilisation de C++ via QT.
Selon vous, est-ce la meilleure bibliothèque concernant les interfaces graphiques? La seule peut être?

[oodini]

Si tu es disposé à resté scotché sur Windows, tu peux faire du C++ et utiliser .Net pour ton IHM. Ou Qt pour du multi-plateformes.

[Kadesh]

Si tu es disposé à resté scotché sur Windows, tu peux faire du C++ et utiliser .Net pour ton IHM. Ou Qt pour du multi-plateformes.

Non je suis intéressé par le multiplateforme justement.

Merci à tous pour vos contributions.

J'attends d'ici ce soir pour voir si quelqu'un n'a pas une chose à ajouter car je veux toujours savoir si c'est la meilleure bibliothèque C++ et je passe en [résolu]

[foetus]

Un avis de "blasé"

Mais en C++, Qt et Boost (le C++11 lorgne sur Boost d'ailleurs) sont [quasi] les seules bibliothèques qui te permettent de faire des interfaces graphiques des threads, ....

Évidement on va me sortir wxWIdgets, GTK, mais pour l'une elle n'est pas super maintenue et pour l'autre avec ses 10-15 bibliothèques.
Pour faire de threading il y a les bibliothèques Intel, OpenMP (mais il faut un compilateur compatible), MPI, mais elles ne font que du threading.

C'est d'ailleurs l'avantage de Boost et de Qt: elles permettent d'apprendre un grand nombre de concepts (pas Qt avec sa conception GUI qui date de 20 ans et du premier MFC) et de brasser un grand nombre de domaines.
Les problèmes:

• Ce sont des bibliothèques lourdes en taille, longues à compiler et que leur dépendance n'est pas "anodine"
• Rien que la blague du MOC mais il ne sert pas qu'à générer du C++ via QObjet, il y a plusieurs utilisations. Sur le site internet officiel, c'est expliqué que sa raison d'être était de bien séparer les concepts pour que cela soit compréhensible: en français on dit "tuer une mouche avec un bazooka"
• Ce sont des bibliothèques qui ont certaines parties pas trop optimisées soit en utilisation CPU soit en mémoire
• La documentation et les exemples qui semblent pléthoriques, sont tous du code "vite-fait", survolé et l'aide Google c'est pareil: vague, imprécise. Prépare toi à morfler ou

Et je rajouterais un autre argument (mais il n'est pas trop vrai); Boost et Qt apportent les briques, l'eau et le ciment et c'est à toi de ramener la bétonneuse et de construire le mur

Un exemple d'"explication floue" pour Qt regarde la classe QSizePolicy

[Kadesh]

Mais en C++, Qt et Boost (le C++11 lorgne sur Boost d'ailleurs) sont [quasi] les seules bibliothèques qui te permettent de faire des interfaces graphiques des threads, ....

Évidement on va me sortir wxWIdgets, GTK, mais pour l'une elle n'est pas super maintenue et pour l'autre avec ses 10-15 bibliothèques.
Pour faire de threading il y a les bibliothèques Intel, OpenMP (mais il faut un compilateur compatible), MPI, mais elles ne font que du threading.

A quoi ca sert de faire des threads? (J'ai lu sur internet que ca sert à faire executer plusieurs tâches simultanées à ton programme, j'ai bien compris?)

C'est d'ailleurs l'avantage de Boost et de Qt: elles permettent d'apprendre un grand nombre de concepts (pas Qt avec sa conception GUI qui date de 20 ans et du premier MFC) et de brasser un grand nombre de domaines.
Les problèmes:

• Ce sont des bibliothèques lourdes en taille, longues à compiler et que leur dépendance n'est pas "anodine"
• Rien que la blague du MOC mais il ne sert pas qu'à générer du C++ via QObjet, il y a plusieurs utilisations. Sur le site internet officiel, c'est expliqué que sa raison d'être était de bien séparer les concepts pour que cela soit compréhensible: en français on dit "tuer une mouche avec un bazooka"
• Ce sont des bibliothèques qui ont certaines parties pas trop optimisées soit en utilisation CPU soit en mémoire
• La documentation et les exemples qui semblent pléthoriques, sont tous du code "vite-fait", survolé et l'aide Google c'est pareil: vague, imprécise. Prépare toi à morfler ou

Quelle incidence ca a qu'une library soit lourde en taille?
QT a une approche obsolète de la création de GUI ?

Et concernant la gestion de la mémoire ca m’embête beaucoup car je voulais optimiser tout ca, j'imagine que c'est obligatoire pour permettre à des utilisateurs avec un vieux pc de profiter d'un programme qui demande des ressources?

J'ai vraiment du mal à tout comprendre en tant que débutant, si tu pouvais être plus simple dans tes explications ca m'aiderait énormément.

Merci pour ta contribution, j'attends ton retour

Tout le monde est d'accord avec foetus sinon?

[PilloBuenaGente]

Tout le monde est d'accord avec foetus sinon?

C'est vrai qu'il aurait été constructif d'argumenter les dislikes.
A moins que les proC++ ne soit un peut trop proC++

[Iradrille]

A quoi ca sert de faire des threads? (J'ai lu sur internet que ca sert à faire executer plusieurs tâches simultanées à ton programme, j'ai bien compris?)

Exactement.

Quelle incidence ca a qu'une library soit lourde en taille?

Gros exécutable ou grosse dll à fournir.

QT a une approche obsolète de la création de GUI ?

Et concernant la gestion de la mémoire ca m’embête beaucoup car je voulais optimiser tout ca, j'imagine que c'est obligatoire pour permettre à des utilisateurs avec un vieux pc de profiter d'un programme qui demande des ressources?

J'ai vraiment du mal à tout comprendre en tant que débutant, si tu pouvais être plus simple dans tes explications ca m'aiderait énormément.

Merci pour ta contribution, j'attends ton retour

Tout le monde est d'accord avec foetus sinon?

Dans l'ensemble plutôt d'accord oui, par contre comparer boost et Qt non.
boost, c'est vraiment bien foutu (et bien optimisé).

Qt je suis pas fan, et il y a énormément de reproche qu'on peut lui faire : le MOC, la QTL (pas directement compatible avec la STL, obligé de faire des conversions, et les fonctions n'ont pas non plus tout le temps le même nom, certaines fonctions sont manquantes). QObject qui est un god object, etc...

Malgré ça, Qt reste la référence pour les UI (faute de mieux ).

[jblecanard]

Salut Kadesh

D'abord mon avis sur Qt. Je ne suis que partiellement d'accord avec foetus. En terme de GUI en C++, Qt est une référence. Elle est codée et maintenue par une entreprise, et même si ce n'est pas en soit une garantie de qualité, il faut savoir que ça fait longtemps qu'ils sont dans la boucle et le projet est toujours bien vivant. Beaucoup de logiciels utilisent Qt (Gimp est franchement un mauvais exemple, sa GUI est pourrie et n'a pas évolué depuis presque 10 ans XD). La dernière version de Qt comporte un énorme refactoring de la base de code et pas mal de réécriture. De fait, les critiques qu'on peut imputer aux versions précédentes ont moins de valeur. Le fait que le framework existe depuis longtemps rend difficile son approche car des tas de tutoriels périmés traînent un peu partout. De fait, il vaut mieux se rapprocher au maximum de la documentation officielle et faire attention à la fraîcheur des tutos consultés.

Maintenant, mon avis sur ton projet personnel. Tu veux apprendre le C++ pour devenir programmeur et te faciliter l'accès à d'autres langages plus tard. Il est vrai qu'un bon développeur C++ aura plus de facilités à appréhender un langage inconnu. Par rapport à Java et C#, la flame war est classique et éculée. Les citations que tu nous a montré contiennent du vrai mais sont clairement rédigées sans grand souci d'objectivité, il y a beaucoup à y redire. Vu ce que j'ai pu lire dans ce thread, tu pars vraiment de zéro en terme de programmation. Je pense qu'une petite mise au point est nécessaire : bien programmer est difficile. C'est un métier, et il ne s'apprend pas en quelques soirées : tu as une masse de travail conséquente à abattre pour devenir un programmeur. Programmer en C++ l'est encore plus, c'est un des langages les plus complexes et les plus difficiles à assimiler correctement. Ce n'est pas pour rien si les développeurs C++ de bon niveau trouvent du travail en claquant des doigts (pour peu qu'ils ne fassent pas la fine bouche sur la moralité du job ).

Si cette activité est un hobby, je pense que commencer par le C++ est vraiment ambitieux. Je te conseillerais plutôt de commencer par un langage plus simple, car ça ne t'empêchera pas de passer sur C++ par la suite. Personnellement, je te conseilles Python. Mais d'autres langages feraient aussi l'affaire, je pense à Java, Ruby.

Si tu te lances dans l'aventure C++ malgré tout, prend garde de pratiquer le C++11 dès le début. De même que Qt, C++ a un lourd passif et on a vite faire de lire des tutos complètement périmés.

Bon courage !

[Bousk]

Mais en C++, Qt et Boost [...] sont [quasi] les seules bibliothèques qui te permettent de faire des interfaces graphiques des threads, ....

Boost pour les interfaces graphiques ?

Évidement on va me sortir wxWIdgets, elle n'est pas super maintenue

WxWidget morte ? la dernière version stable 3.0 est sortie le 11 novembre dernier
WxWidget est un très bon choix pour moi, elle est simple à utiliser, et répond aux besoins simples de la création d'UI
GTK je ne l'ai jamais utilisé

Pour faire de threading il y a les bibliothèques Intel, OpenMP (mais il faut un compilateur compatible), MPI, mais elles ne font que du threading.

Bienvenue dans le C++, où il existe de nombreuses bibliothèques spécialisées, et ce qu'on demande à une bibliothèque spécialisée c'est de remplir sa tâche, pas en plus de faire le café et ramener un sandwich
TBB (Threading Building Boxs) est un bon choix de bibliothèque de threading, encore une fois très simple à utiliser

(pas Qt avec sa conception GUI qui date de 20 ans et du premier MFC)

Cite-moi une bibliothèque de GUI récente et à la conceptio correcte de référence ?
Certains choix de Qt sont peut-être discutables (le god object en particulier), mais ils sont inhérents à la conception GUI et à la complexité d'un tel moteur
Le seul point négatif c'est la chaine de compilation, ou alors on peut être malin et utiliser Qt Creator

[*]Ce sont des bibliothèques lourdes en taille, longues à compiler et que leur dépendance n'est pas "anodine"

Une grande partie de Boost est header-only, ses dépendances sont très claires, aucun include n'est superflu
Quant à Qt.. tu l'utilises ou pas, mais quand tu l'utilises c'est entièrement. Là encore c'est le principe d'un moteur de GUI, tu peux pas dire "j'utilise Qt avec les boutons de WxWidget", ça n'a aucun sens

[*]Rien que la blague du MOC mais il ne sert pas qu'à générer du C++ via QObjet, il y a plusieurs utilisations. Sur le site internet officiel, c'est expliqué que sa raison d'être était de bien séparer les concepts pour que cela soit compréhensible: en français on dit "tuer une mouche avec un bazooka"

Oui les MOC c'est chiant à l'usage au départ, à moins d'utiliser Qt creator
Pour le reste, les MOC sont tout de même un "moins mauvais" (voire un bien meilleur) choix qu'autre chose, et c'est expliqué sur leur site http://qt-project.org/doc/qt-5/why-moc.html

[*]Ce sont des bibliothèques qui ont certaines parties pas trop optimisées soit en utilisation CPU soit en mémoire

Qt est tout de même grand public, et sa complexité rend surement certaines parties "moins bonnes", pour être fonctionnel
Et puis bon, l'utilisation CPU d'une GUI dont la principale utilisation est d'attendre un input utilisateur..
Pour Boost, cite-nous un morceau qui rentre dans ta description, je suis sceptique, il s'agit tout de même de codes de qualité

[*]La documentation et les exemples qui semblent pléthoriques, sont tous du code "vite-fait", survolé et l'aide Google c'est pareil: vague, imprécise. Prépare toi à morfler ou

L'ancienneté des bibliothèques fait qu'il existe de nombreux exemples.. obsolètes. Ce n'est pas à imputer aux bibliothèques mais aux sites qui proposent toujours un tel contenu

Et je rajouterais un autre argument (mais il n'est pas trop vrai); Boost et Qt apportent les briques, l'eau et le ciment et c'est à toi de ramener la bétonneuse et de construire le mur

A part du bash gratuit des bibliothèques cités, je vois absolument pas le sens de ta remarque..
Si construire le mur n'est pas de ton ressors, fais appel à un professionel, mais ne blame pas les outils

[Iradrille]

Le seul point négatif c'est la chaine de compilation, ou alors on peut être malin et utiliser Qt Creator

On peut garder son IDE favori, qmake génère des fichiers projets pour un grand nombre d'IDE différents.

Quant à Qt.. tu l'utilises ou pas, mais quand tu l'utilises c'est entièrement.

C'est bien là le problème : que se soit la STL ou la QTL, elles ne proposent que les algos de base et on utilise boost dès qu'on a besoin d'un algo qui sort un peu de l'ordinaire. Et donc on se retrouve avec des conversions entre les types Qt / STL un peu partout.

[foetus]

En terme de GUI en C++, Qt est une référence. Elle est codée et maintenue par une entreprise, et même si ce n'est pas en soit une garantie de qualité, il faut savoir que ça fait longtemps qu'ils sont dans la boucle et le projet est toujours bien vivant.

Cite-moi une bibliothèque de GUI récente et à la conceptio correcte de référence ?

Lorsque tu connais la programmation XCode/ MAC/ Objective-C tu comprends vite la différence.

Et tu confirmes ce que je dis: Qt n'a pas vraiment bouger depuis des lustres (je trouve aussi que cela rassure).
Le seul truc c'est le Qt Quick puisqu'actuellement il faut impérativement faire du mobile.
Microsoft a rajouter les rubans dans MFC depuis au moins 2010.

Boost pour les interfaces graphiques ?

Non avec Qt, c'est la bibliothèque plus ou moins à connaitre.
Et Qt fait des threads aussi

Une grande partie de Boost est header-only, ses dépendances sont très claires, aucun include n'est superflu
Quant à Qt.. tu l'utilises ou pas, mais quand tu l'utilises c'est entièrement. Là encore c'est le principe d'un moteur de GUI, tu peux pas dire "j'utilise Qt avec les boutons de WxWidget", ça n'a aucun sens

Qt c'est comme Boost: tu as vu le nombre de DLLS que ces bibliothèques te génèrent.
C'est vrai qu'elles brassent un grand nombre de concepts, mais niveau temps de compilation, dépendance DLL ce n'est pas négligeable.
Et je ne parle pas des dépendances externes. Par exemple, lorsque tu compiles les shared_ptr es-tu sûr que le compteur est protégé par des mutex?

Oui les MOC c'est chiant à l'usage au départ, à moins d'utiliser Qt creator

Qt creator c'est quand même un IDE en carton-pâte.
La dernière fois j'ai voulu rajouter une bibliothèque externe: je l'ai fait à la main dans le fichier .pro.
Et un autre truc Qt creator ne ferme pas les fichiers source lorsque tu fermes un projet.
Un dernier: pourquoi Qt creator (mode wiswig) te créé tous tes centralWidget en Widget* alors que tu es obligé d'avoir un layout.

Et puis bon, l'utilisation CPU d'une GUI dont la principale utilisation est d'attendre un input utilisateur..
Pour Boost, cite-nous un morceau qui rentre dans ta description, je suis sceptique, il s'agit tout de même de codes de qualité

J'ai regardé un article Internet sur les boost::shared_ptr VS new. Sans les optimisations le new est au moins 2 fois plus rapide.

On revient au même: Boost et sûrement Qt ont des pans entiers qui sont optimisés mais il faut avoir les bibliothèques bien compilées à la base.
Mais tu peux toujours trouver un truc non optimisé comme optimisé.

L'ancienneté des bibliothèques fait qu'il existe de nombreux exemples.. obsolètes. Ce n'est pas à imputer aux bibliothèques mais aux sites qui proposent toujours un tel contenu

Regardes bien les exemples de Boost 1.55 ou de Qt 5.2.
Regardes en passant le nombre d'exemple pour les Qt Widget (parce que le Qt Quick je m'en fiche pour le moment)

Est-ce que tu trouves un exemple sur les QSizePolicy, les strechs?

Alors oui un grand nombre d'exemples sur Internet sont périmés, mais cela m'a permis de trouver la méthode mouseDoubleClickEvent

Si construire le mur n'est pas de ton ressors, fais appel à un professionel, mais ne blame pas les outils

Prenons un exemple: les UI Tools. Je trouve cela mal fichu un outil qui te permet de créer une fenêtre en mode wiswig, mais dans ton code tu te retrouves avec un gros objet ui et c'est à toi d'aller chercher tous les pointeurs, limite faire les connect.
Un autre exemple: la localisation. Tu dois aller chercher ton fichier qXXX et le donner à manger à ton objet qApplication (il me semble)

Donc oui, Qt, comme Boost, te propose un grand nombre de classes, helpers, ... mais c'est au développeur de savoir les utiliser parce qu'ils t'aident pas plus que cela.
D'autant plus qu'il y a souvent des subtilités de Sioux.