Discussion :

[SalutAVous]

Bonjour,

J'apprends Qt et Boost et je me demandais si je pouvais utiliser des bibliothèques de Boost avec Qt. Je pense que oui mais en fait j'aimerais comprendre l'intérêt de faire cela (si la réponse est oui bien sûr...)

J'ai l'impression que Qt permet de faire tout ce que l'on veut. Je prends un exemple : pour utiliser les expressions régulières avec Qt il existe QRegExp. Peut on à la place utiliser la bibliotheque Boost.Regex ?

Si oui, quel est l'intérêt d'utiliser Boost.Regex à la place de QRegExp dans un projet Qt ?

S'il n'y a aucun intérêt, quand peut on utiliser Boost ? Pour quels types de projet ? Pour des projets autres que des projets GUI ?


Voilà des questions qui perturbent le débutant que je suis.
J'espère que vous prendrez la peine d'y répondre.
Bonne journée.

[koala01]

Salut,

En fait, tu n'apprends ni boost, ni Qt (enfin, je l'espère pour toi ) mais tu apprends C++ et tu apprends à utiliser boost et Qt

Ceci dit, oui, il y a parfaitement moyen d'utiliser boost et Qt ensemble, et, oui, cela présente bien souvent certains avantages.

Le fait est que Qt est quelque peu... intrusif lorsqu'on l'utilise à mauvais escient (ceci dit sans vouloir retirer le moins du monde à la qualité du framework ):

Qt fait (à juste titre) l'apologie du concept MVC pour la gestion des données, et il a bien raison, mais...

Mais le fait est que, si tu utllises Qt pour tout ce qui concerne la partie métier de ton application (comprends : les données que tu manipules, les règles qui s'appliquent à ces données et les relations qui existent entre elles), il te sera très difficile de ne pas tout devoir "jeter à la poubelle" si tu décides un jour de changer de bibliothèque IHM.

En effet, même lorsque tu peux te permettre de ne pas utiliser les composants visuels, QString, QList et autres QMachinChoses n'ont strictement rien de standard et n'existent... que dans Qt.

L'idéal est donc de faire en sorte que toute la partie métier de ton application n'utilise en définitive que le C++ "standard" (std :: vector ou std :: list au lieu de QList, std :: string au lieu de QString, ...)

Et c'est là que boost peut s'avérer des plus intéressant car boost peut etre considéré comme une extension du standard qui préfigure, dans une certaine mesure en tout cas, ce que le standard sera dans quelques années. (tu n'imagines pas le nombre de fonctionnalités en tous genres qui ont été reprises de boost dans TR1 ou dans C++11 )

En effet, ta partie métier sera sans doute ce qui sera le plus stable dans ton application et peut parfaitement être réutilisée dans d'autres applications qui, tout le monde étant libre de ses choix, décideraient d'utiliser une autre bibliothèque IHM (voire pas de bibliothèque IHM du tout).

Il serait alors dommage que ta partie métier dépende de Qt pour toute une série de choses aussi "basiques" que des collections d'objets, des chaines de caractères ou ... des expressions régulières.

Le fait d'utiliser boost sera beaucoup moins contraignant pour ta partie métier car c'est une bibliothèque qui ne fait "rien de plus" que ce que le langage permet à la base et qui, surtout, n'utilise rien de plus que ce que le standard fournit à la base.

Tu pourrais donc parfaitement décider d'utiliser boost (pour ce qui t'intéresse dedans) dans ta partie métier et Qt pour tout ce qui a trait aux parties "visuelles".

L'énorme avantage est, en outre, qu'il te sera beaucoup plus aisé de créer des tests unitaires sur ta partie métier si elle ne dépend pas de Qt

[gbdivers]

J'ai mis +1 à koala01 sans problème, il a raison.
D'un autre côté, il est également possible d'écrire une application "full Qt" qui sera aussi évolutive et maintenable (et gagner à ne pas manipuler plusieurs types pour la même chose)

Le plus important (à mon avis), c'est surtout que le choix des libs et la place qu'on veut leur laisser dans l'application doit être un choix conscient et raisonné. Par défaut, si on sait pas ou si on n'a pas d'arguments spécifiques pour faire du "full Qt", le plus sur est probablement de ne pas utiliser Qt en intrusif

[SalutAVous]

Oui j'apprends à utiliser Boost et Qt

Donc en fait si je veux pouvoir bénéficier des avantages de Boost dans un projet utilisant Qt il ne faut pas que je fasse un projet "full Qt".

Il faudrait que je me débrouille pour mettre en place une architecture multicouche et utiliser Qt uniquement pour la partie présentation ?

Cela veut dire que si je veux utiliser Boost dans un projet Qt, adieu QList, QString, etc... mais je garde uniquement les QPushButton et autres QWidgets (tout ce qui concerne l'affichage et uniquement l'affichage en fait...)

Et pour les projets de petite taille ne nécessitant pas de fonctionnalités très évoluées je peux me permettre de faire du "full Qt" ?

[koala01]

Oui j'apprends à utiliser Boost et Qt

Donc en fait si je veux pouvoir bénéficier des avantages de Boost dans un projet utilisant Qt il ne faut pas que je fasse un projet "full Qt".

Il faudrait que je me débrouille pour mettre en place une architecture multicouche et utiliser Qt uniquement pour la partie présentation ?

Cela veut dire que si je veux utiliser Boost dans un projet Qt, adieu QList, QString, etc... mais je garde uniquement les QPushButton et autres QWidgets (tout ce qui concerne l'affichage et uniquement l'affichage en fait...)

Et pour les projets de petite taille ne nécessitant pas de fonctionnalités très évoluées je peux me permettre de faire du "full Qt" ?

Non, en fait, tu ne m'as pas compris...

Tu peux facilement utiliser boost, y compris si tu as recours aux fonctionnalités de Qt (un boost::for_each fonctionne sans problème avec une QList), il "suffit" juste de savoir quand il est utile de recourir à boost plutôt qu'à Qt

Mais, de manière générale, il est largement préférable de faire la distinction entre la partie "métier" (le modele) et la partie qui va utiliser les fonctionnalités de Qt, de manière à "au moins ne pas perdre cela" si "les circonstances font que"

C'est à ce moment là que tu trouveras sans doute le plein intérêt d'utiliser boost, mais cela n'empêche nullement d'y trouver un intérêt malgré le fait que ta partie métier utilise Qt...

Il y a en effet de nombreux concepts fournis par boost que tu ne retrouve absolument pas dans Qt, comme, par exemple, la gestion de graphes

[SalutAVous]

Ok j'ai compris

En fait on pourrait très bien utiliser des QList, QVector et autres pour gérer les données de son programme mais si l'on veut quelque chose de réutilisable par la suite (changement de bibliothèque IHM, utilisation dans un autre projet, etc...) on utilise à la place le C++ standard (et donc boost si l'on veut)

Plus j'utiliserais le C++ standard dans mon projet (et donc moins j'utiliserais les fonctionnalités Qt) et plus j'aurais de code réutilisable par la suite, il ne dépendra en effet plus de Qt. J'aurais alors "juste" à modifier ce qui dépendra de Qt.

Par contre un projet "full Qt" m'a l'air plus facile à réaliser qu'un projet utilisant Qt et Boost (mais c'est normal je pense)

[koala01]

Ok j'ai compris

En fait on pourrait très bien utiliser des QList, QVector et autres pour gérer les données de son programme mais si l'on veut quelque chose de réutilisable par la suite (changement de bibliothèque IHM, utilisation dans un autre projet, etc...) on utilise à la place le C++ standard (et donc boost si l'on veut)

En simplifiant, c'est ca...

Plus j'utiliserais le C++ standard dans mon projet (et donc moins j'utiliserais les fonctionnalités Qt) et plus j'aurais de code réutilisable par la suite, il ne dépendra en effet plus de Qt. J'aurais alors "juste" à modifier ce qui dépendra de Qt.

En effet, et c'est une bonne habitude à prendre que d'essayer de travailler sur base du standard et de boost plutot que de tout faire à base de Qt

Par contre un projet "full Qt" m'a l'air plus facile à réaliser qu'un projet utilisant Qt et Boost (mais c'est normal je pense)

Il n'est pas plus difficile d'utiliser boost avec Qt que d'utiliser Qt sans boost...

Cela se gère exactement de la même manière au niveau du projet, en ajoutant

1. le chemin d'accès vers le fichiers d'en-tête pour la compilation
2. le chemin d'accès vers le dossier qui contient les bibliothèque et
3. l'indication de la bibliothèque à utiliser pour l'édition de liens

Alors, bien sur, il y a tout ce qui tourne autour de l'apprentissage, aussi bien C++, de boost que de Qt... Et il est vrai que, l'un dans l'autre, il est préférable de ne pas se tromper dans l'ordre dans lequel on apprend tout cela

L'idéal est d'apprendre le C++ "standard" pour commencer puis d'apprendre à utiliser boost (pour tout ce qu'elle offre en supplément) et enfin d'apprendre à manipuler des IHM (comme Qt).

Si tu tentes de suivre un ordre différent, tu risques de passer à coté de principes ou de bases qui risquent très rapidement de te faire cruellement défaut par la suite

Qu'il te suffise de voir le processus de compilation de Qt, avec l'introduction de qmake et des mocs pour comprendre que la compilation sous Qt rajoute des étapes non essentielles à la chaine de compilation "classique"...

Or, Qt, malgré tout le bien que je peux en penser, n'est jamais qu'une bibliothèque comme une autre, et tu apprendras beaucoup plus sur l'utilisation "classique" des bibliothèques en apprenant à utiliser boost avant d'apprendre à coder de "zoliez interfaces graphiques"

[SalutAVous]

J'ai déjà appris Qt et en ce moment j'apprends Boost. J'apprendrais le C++ par la suite.

Plus sérieusement, je vois maintenant ce qu'il me reste à faire.

Merci pour toutes ces réponses