Salut,
 
je suis en train de développer une petite application en C++. Jusqu'alors c'était tout en mode console, codé en C++ avec la STL et Boost mais maintenant j'ai rajouté une UI en QT et je me demande si mixer QT avec la STL est une bonne chose. Pas mal de classes qui me sont nécessaires existent des 2 cotés et je ne sais pas trop ce qui est le plus malin.
 
Pour l'instant je limite le QT à la partie UI, mais QT n'est plus seulement un framework graphique c'est un framework de programmation complet donc ce n'est pas forcément intelligent.
 
Après j'ai toujours besoin de Boost pour Spirit là, je n'ai rien vu d'équivalent dans QT, pour le reste probablement pas.
 
 
 
Des avis?
 
Merci

Salut,

Concernant la SL vs Qt (et non pas QT ), tout dépend de la portabilité que tu veux obtenir. Le problème étant que certaines implés de la SL sont cassés sur certaines plate-formes, et que TT garanti le bon fonctionnement des conteneurs sur toute plateforme listée comme supportée.
Concernant Spirit, il n'y a effectivement aucun équivalent dans Qt.

l'ordre de préférence est :
 
BOOST >> QT >> STL si tu fais du GUI
sinon BOOST >> STL
 

 
Pour l'instant je fais du win32 sous VS donc portabilité pas importante (bien que mon code est standard). C'est plus pour me donner des bonnes habitudes que je demande
 

 
Tu as des raisons particulières pour ces classements? je pense essentiellement à Boost >> Qt dans le cas d'une GUI.
Qui plus est, tu es donc contre utiliser Qt si pas de GUI?
 
 
Merci

Boost ne propose pas, je crois de moyen de faire de GUI, donc, l'assertion "Boost >> Qt" est fausse si tu veux faire de la Gui. Si tu veux faire uniquement du texte, alors, c'est probablement vrai.
 
Sinon, boost est assez portable (en tout cas, ça existe sous Linux et *BSD) et je crois que KDE4, basé sur Qt4 utilise également boost pour certaines parties, donc...
Le mieux est de choisir, quand tu as la choix entre les deux celui qui te convient le mieux :
ce que tu veux faire / fonctionnalités offertes
ton niveau / complexité de l'API

 
je parlait des API hors GUI. OFC qu'y a pas de gui dans boost
dooonc, on reprend :
 
une appli Qt qui a besoin de classes de haut niveau non-gui related : boost en prems puis les classes QT natives puis STL

Ma petite opinion sur cette question: tout dépend de ce que tu veux faire; sans gui, tu as accès à tout les modules ne dépendant pas de QtGui, dont certains n'ont pas d'équivalent dans boost (network, sql ou script pour ne citer qu'eux).
Bien sûr, tout peut être assemblé à partir d'autres bibliothèques, donc c'est vraiment dépendant de ce que tu cherches à faire.

bah je cherche à bien coder

 
bah  
 
network : raknet
sql : sql++
scritp : lua++
 
ca m'embete de trimballer els dll QT ou un exe maousse rien que pour lire du xml par exemple.

et le memory footprint? embarquer du Qt ca coute cher?

asio pour le network ?

D'où la dernière phrase de mon post et le fait que j'insiste sur le fait que ça dépende du contexte (admettons un bon vieux serveur qui n'est destiné qu'à des applis Qt)

Ca occupe 37 Mo sur mon disque (sous Linux).

C'est pas en mémoire ça, c'est le contenu du répertoire bin avec dlls de debug/release + outils.
Mais c'est vrai que Qt est relativement lourd de toute façon (tout dépend des modules utilisés). Pour une petite appli utilisant core/gui/sql/xml (plus quelques plugins satellites) et sans y charger de base sqlite, j'atteinds 12 megs de charge (17 en chargeant un fichier d'environ 1 megs).
Pour de plus grosses applis, je ne saurais te dire

ok je vois ce que vous voulez dire.

Mais c'est chaud alors d'être un bon programmeur, faut connaître plein de frameworks / bibliothèques

Bon suivant vos commentaires je pense que je vais rester en Boost/STL dans le core, et Qt dans la partie GUI, mais ca fait bizarre je trouve de se trimballer des QString par endroit et des std::string aillieurs.

Qt ca a l'air sympa sinon, bien que parfois c'est la grosse galère je trouve pour comprendre comment faire un truc tout simple (genre j'ai du passer plus d'une demi journée sur QTableWidget).

Merci

De ce que je lis à droite à gauche, être un bon programmeur, c'est plutôt savoir s'adapter, et donc savoir apprendre/évoluer, ceci allier à de bons principes de conceptions, d'écritures etc... Le travail de toute une vie en somme

Pour cet exemple, j'utilise QString un max parce que ça t'apporte une localisation extrêmement facile, alors que les string ne gère absolument pas divers codecs. Donc, encore une fois, utilise ce qu'il faut où il faut (Genre, si tu as des chaînes dans le coeur d'un soft utilisant de toute façon Qt, et que ces chaînes sont susceptibles d'être traduite/affichée, alors autant utiliser QString directement, tu éviteras des conversions internes.)

Bah sinon au lieu d'isoler le GUI je pourrais isoler Spirit et envoyer du QT sur tout le reste.

ca parait mieux

et pourquoi

Rencarde toi sur le pattern Model-View-Controller

je connais déjà mais je ne vois pas lke rapport là.

c'est toujours une bonne idée de séparer son interface de son code applicatif.
Dans le meilleur des mondes, tu devrais pouvoir commencer par ecrire ton code en console (sauf ofc besoin impérieux de GUI pr rentrer les données et encore) et le coder en utilisant des trucs standards (STL+BOOST).
Une fois cet applicatif fini, tu atatques la partie GUI (avec QT) et tu utilises deux-trois adaptateurs pr integrer ton code applicatif dedans.
 
Au final, l'applicatif n'utilise pas de QT, et la GUI n'utilise que ça.

bah c'est bien ce que je disais alors
Quand j'ai dis isoler Spirit c'est un peu l'inverse de ce que tu proposes.
 
Bon par contre ce qui est embétant c'est que j'ai écrit une fonction qui travaille sur du QString et que j'ai besoin d'exactement la même chose pour des std::string

elle fait quoi cette fonction ?

fonction template

la fonction me récupere le nom d'un fichier à partir du filepath.
Je pourrais le faire en template j'imagine oui, mais les 2 classes n'ont pas les mêmes noms de fonctions donc ca fera autant de code que 2 fonctions je pense ;(

"la fonction me récupere le nom d'un fichier à partir du filepath. "
utilise boost::filesystem

Je vais regarder merci mais ca parait gros pour les 4 lignes de code dont j'ai besoin.
De plus ca ne fonctionnera toujours pas avec mes QString
 
 
Merci

Pour les QString, tu peux utiliser QFileInfo, ça te permet d'obtenir pas mal de renseignements sur un fichier, dont ce que tu cherches. (Si bien sûr tu restes sur QString, ou que tu as réellement besoin des 2.)

en fait, le truc c'est de voir quid de qstring ou de string permets de couvrir le plus de besoins. En gros, minimise les changements

bah hors UI et hors Spirit pour l'instant ca m'est égal je pense.
Par contre si QFileinfo est plus petit à comprendre que Boost::Filesystem ca m'interessera plus

bon QFileInfo fait exacement ce que je veux, mais ca me coute un objet en plus, je prend mais je trouve cela dommage d'avoir un objet pour une fonction

Sinon vous savez comment ouvrir un Browser depuis QT?
J'ai trouvé quelques méthodes, mais c'est souvent non portable, et même si mon appli n'a pas pour but de l'être j'aimerai toujours avoir un code portable pour moi même...
 
Merci

Depuis Qt4.32, tu as accès à QDesktopServices, qui ne s'occupe pas que du browser.
Sinon, ce n'est pas inclus dans Qt. Si tu veux vraiment te restreindre au browser (ou plutôt "peux te restreindre..." ), il y a une fonction ici qui est sensée faire ça sur Win, OSX et Linux. Je ne l'ai pas testé, mais à vue de nez, ça devrait fonctionner (bien que ne connaissant rien à OSX...).
 
Edit: lien

C'est parfait QDesktopServices, merci beaucoup.
Je cherchais depuis vendredi sur "qt open browser" mais je n'avais trouvé que des vieux hacks en QT 2.XX.
Tu connaissais ou bien tu as trouvé là? et si oui par quel moyen?
 
 
Merci

Je connaissais déjà

Encore une ptite question vu que tu as l'air de t'y connaître ^^.
J'ai un QTableWidget, mais au niveau du header j'ai 3 divisions alors que moi je n'en veux que 2 (et column me retourne bien sûr 2).

Je ne comprend pas trop ce qui se passe et de nouveau je n'ai rien trouvé.
A part cela c'est fini je pense, bon par contre j'ai clairement aucun talent en design

edit : bah en fait un setResizeMode(QHeaderView::Stretch); a suffit donc c'est cool

Merci

arf j'ai compilé mon appli en static pour éviter de devoir me trimballer les dlls de QT et autres, et hop 4 Mo à la place des 130Ko de base (que je trouvais déjà enorme).
1.4 Mo en UPX, c'est déjà mieux mais je ne suis pas convaincu que j'ai le droit de me trimballer de l'UPX...

ne aps oublier un coup de strip

tu veux virer les espaces blancs dans quoi? je ne comprend pas trop.