Aller plus loin
- Qt contre MFC (318 clics)
- Qt vs MFC (70 clics)
Qt contre MFC
23
juil.
2002
Je publie sur mon site une comparaison entre la programmation avec des MFC et la programmation avec Qt. Aucun doute permis sur lequel est le plus puissant! On est bien sur intêressé par des retours de tous types: erreurs, expériences similaires ou contradictoires, etc
# Article intéréssant...
Posté par Dawm . Évalué à 10.
En ce qui concerne le pseudo objet vs object, oui, c'est une évidence mais ce n'est pas vraiment la faute des MFC. Le fait est que toutes les surcouches comme MFC, WTL, ATL sont toutes fortement dépendantes de l'API Win32, qui est massivement écrite en C. Ca a des raisons, en particulier le faite que les bases de l'API n'ont peu ou prou pas changés depuis Windows 3.x, donc à une époque où le C++ n'était pas aussi fortement répandu. Donc d'un côté, c'est bien parce que la compatibilité ascendante est fortement assurée (99% des exe compilés pour win95 tournent sous winXP) mais de l'autre, effectivement, on reste dans un vieux modéle C.
La boucle de messages. Effectivement, elle demande un peu d'apprentissage. Néanmoins je trouve qu'à l'usage elle se révéle assez pratique et fait partie des quelques concepts à bien maitriser pour développer sous Win32. Est elle améliorable, sans doute, est ce vraiment un handicap : je ne pense pas
Au niveau de la simplicité de coding, je ne vois pas de grandes différences...
Si tu veux faire un EditBox en API, tu vas faire un CreateWindow avec les paramétres qui vont bien et voilà.
Sur la doc, certes MSDN n'est pas très facile à maitriser, mais c'est certainement la plus grosse base de documentation sur un OS qui existe. Et tu oublies de parles des newsgroups microsoft.* ou autres ng dans les hiérarchies "classiques" dans lesquels des développeurs experimentés Win32 api foisonnent, voir même des propres développeurs Microsft pour les ng ms.* Je ne peux pas préjuger de la qualité de la doc de Qt ne l'ayant pas lu ni pratiqué, mais honnêtement je ne me souviens pas avoir eu un probléme sans trouver la solution dans les 1 à 2 heures suivantes en win32 API (et c'est encore plus vrai en MFC vu le nombre de sites dédiés).
Les CString sont une daube, aucun doute là dessus. Mais pourquoi ne pas utiliser std::string qui convient dans 95% des cas ?
Tu dis qu'il n'y a pas de ressources dans QT, mais quel autre systéme remplit ce rôle alors ?
Sinon pour moi, le gros avantage de QT c'est avant tout qu'il est multiplateformes.. C'est un réél intêret pour celui qui veut développer un prorgramme graphique à destination de plusieurs OS
[^] # Re: Article intéréssant...
Posté par Fabimaru (site web personnel) . Évalué à 10.
Par contre les MFC ont ete concues il y a longtemps (dans ces temps recules ou le "bool" et le RTTI n'existait pas), et leur design n'a pas ete fondamentalement change depuis.
Quant a l'article, je lui reproche les petites phrases comme On s'étonne qu'ensuite le C++ ait la réputation de planter bizarrement. Ca ne fait pas tres serieux !
L'ideal serait un comparatif entre plus de bibliotheques (Swing, WxWindows, GTK...) pour savoir comment elles transforment une API pas tres objet (boucle de messages...) en un truc objet.
[^] # Re: Article intéréssant...
Posté par WildChild . Évalué à 10.
Il est certain que QT est utile pour ça mais il utilise son propre visuel qui peut ajouter des limites à ce que le programmeur peut faire selon les cas.
[^] # Re: Article intéréssant...
Posté par hugo . Évalué à 10.
Sur un ordinateur puissant, ça passe joliment, et le nouvel IDE d'IBM (eclipse, opensource) en fait un usage abondant.
http://www.eclipse.org(...)
A+ Hugo
[^] # Re: Article intéréssant...
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Un peu comme SWT, quoi : http://www-106.ibm.com/developerworks/java/library/j-nativegui/?t=e(...)
Ce toolkit java est une alternative à AWT et offre des widgets qui seront implémentés par les widgets de l'API sous-jacente (win32, gtk, ...) quand c'est possible, ou par des widgets faits à la main le reste du temps.
[^] # Re: Article intéréssant...
Posté par Philippe F (site web personnel) . Évalué à 10.
C'est ce que fait Qt. Win32 sous Linux, XWindow sous Linux et Macos X, FrameBuffer sous applications embarquees.
> Ça aiderais beaucoup à faire des applications facilement portable d'un système à l'autre
Qt est justement l'ideal pour faire des applications portables. Tu n'as besoin que d'une recompilation.
> en utilisant leurs API graphiques natifs. (Performances des logiciels?)
Qt se base sur les API natives tres bas niveau. Donc l'apparence est emulee. Mais sous windows, elle est mieux emulee que windows lui-meme. Etonnant ? Ce que je veux dire, c'est que windows a des incoherences dans ses toolbar par exemple, que Qt n'a pas.
Si tu achetes une licence Qt, tu recois un papier qui explique leur choix de se baser tres bas-niveau. Ce que tu demandes a ete fait par WxWindows. Les problemes que ca entraine sont que cela pose beaucoup plus de contraintes sur l'architecture de ta bibliotheque. Qt a le controle complet et ne depend en gros que de la capacite de l'OS a dessiner des lignes et a bouger une fenetre. Qt est donc bien plus facile a porter. Et des qu'une nouvelle foncitonnalite existe sous Qt, elle est disponible sur toutes les architectures. Ce n'est pas le cas de WxWindows.
> Et en même temps faire de quoi qui serait facile d'utilisation peut importe le OS.
C'est Qt que tu decris la (dans une syntaxe un peu etrange).
> Il est certain que QT est utile pour ça mais il utilise son propre visuel qui peut ajouter des limites à ce que le programmeur peut faire selon les cas.
Ton argument est bien theorique. En trois ans d'utilisation de Qt, je n'ai jamais rencontre les limites dont tu parles. Au contraire, grace a Qt, j'ai pu depasser les limites de ce qui etait present de base sur le systeme d'exploitation.
[^] # wxWindows
Posté par Erwan . Évalué à 7.
- wxWin32
- wxGtk
- wxMac
En utilisant les widgets natifs de chaque plateforme a chaque fois. Il y a aussi un port wxUniversal qui dessine lui-meme ses widgets (comme Qt) et permet de porter plus rapidement wxWindows ou de porter sous une plate-forme sans toolkit. Il y a par exemple un port pour DOS...
[^] # Re: Article intéréssant...
Posté par blackshack . Évalué à 10.
Le pied, de plus développement plus rapide, et même grâce aux classes du type QFileInfo, les fonctions d'automatisation utilisant le même logique de fonctions que j'avais crée, sont au moins 100 fois plus rapide. En effet pour les sortie l'ancienne version avec les MFC mettaient pour l'automatisation de la gravure de 10Go d'images des heures -j'exagère un peu -c une expression hein- mais pas tellement- là, avec Qt, cela va tellement vite que l'affichage des logs de retour -prise en compte de telle commande, création des fichiers de sortie et autre- n'a pas le temps de se rafraîchir entre deux informations, et il faut avoir soit une erreur soit attendre la fin de la tâche pour pouvoir lire le log... :-) (je précise que cela ne prend pas en compte la gravue que le prog ne s'occupe pas d'ailleurs il n'est qu'un tampon entre un robot -avec ses propres serveurs de création d'image et gravure- et l'utilisateur, il permet de prendre en entré un répertoire aussi gros soit il avec quelques informations -titre de la série, contenu..- et avoir en sortie les ordres et les descriptions des X cds de 650Mo avec les labels personnalisés pour chaque d'entre eux devant être imprimé sur le cd, destinés au robot de gravure.
En clair un gain en production pouvant aller jusqu'à 1heure-1heure30 pour chaque collection à gravé.
[^] # Re: Article intéréssant...
Posté par pasBill pasGates . Évalué à -2.
Juste comme ca, en regardant les softs existant, et en voyant que certains y arrivent tres bien.
[^] # Re: Article intéréssant...
Posté par blackshack . Évalué à 4.
[^] # Re: Article intrssant...
Posté par kangs . Évalué à 3.
[^] # N'importe quoi ...
Posté par _ _ . Évalué à 5.
1) la pénalité d'abstraction différente imposée par chaque API
2) le choix d'un algorithme avec une complexité désastreuse
3) un probleme de bufferisation
--
1) n'est probablement pas la bonne explication, car une pénalité d'abstraction se mesure en dizaine de %, or là tu nous parle d'un ralentissement d'un heure et demie ...
2) l'algorithme est quelque chose de beaucoup trop dépendant de l'appli pour être codée dans une classe de bas niveau comme CFile ou QFile.
Donc ici l'API n'est pas en cause.
3) Certaines API proposent une bufferisation automatique d'autres manuelles, chaque solution ayant ses avantages et ses inconvénients : facilité d'utilisation pour le premier, performance meilleure (car mieux adapté à l'appli) pour l'autre.
A ce niveau l'API utilisée peut-être en cause mais sans doutes beaucoup moins que le développeur qui n'a pas su lire sa documentation pour paramétrer correctement sa bufferisation.
Donc, d'après la description du problème, il me semble effectivement, que l'appli soit plus en cause que QT ou MFC. Si tu nous avais parlé d'un problème de perf de quelques pourcents, je ne dis pas mais là non.
Quand à ta réponse,Il a du faire avec les erreurs de design des MFC, elle pourrait se résumer en "c'est celui qui dit qui y est".
J'attends un argument plus pointu pour venir etayer cette affirmation.
# Intéressant
Posté par WildChild . Évalué à 10.
Un gros avantage c'est la portabilité. Avec QT, il est facile de faire des applications Windows/Linux avec très peu de modifications au code.
En plus dans l'arcticle on compare très bien QT et les MFC et on peut voir ses avantages. Maintenant il ne me reste qu'à commencer mon projet histoire de réellement voir si QT c'est aussi facile et performant qu'on le dit!
[^] # Re: Intéressant
Posté par kangs . Évalué à 2.
des conteneurs, les fonctions de tries sont membres
des class, si en fonction du context tu dois trier
différemment ca devient de la bidouille.
# Du vécu !
Posté par One . Évalué à 10.
En ce qui concerne la licence qt (1500$) pour les plateformes Microsoft, je trouve cela valable et à encourager. Etonnant pour un fervent défenseur du libre, mais Je m'explique : le monde selon Microsoft doit être un monde de licences, de codes fermés et de gros sous. Faire payer les users microsoft est normal, car nous devons respecter leur logique. L'ensemble des logiciels GPL est à la disposition de toute entreprise voulant les utiliser. Tout est mis en oeuvre pour encourager les développements de type GLP, mais certains n'en veulent pas pour des questions de "secret defense", donc faisons les payer un max. Et peut-être qu'un jour comprendront ils que l'intérêt de tous passe par les licences de type GPL et que le monde selon Microsoft n'est pas la voie royale, pour la reconnaissance.
L'article est à mettre dans la catégorie "Argumentation solide pour passer à GPL". Encore Bravo mon gars.
[^] # Re: Du vécu !
Posté par WildChild . Évalué à 10.
Pour ce qui est du prix, 1500$ c'est dans la normale pour une utilisation commerciale d'une telle chose vu l'argent qu'ils peuvent récolter en retour avec la vente des applications. C'est le monde de Windows quoi! :)
[^] # Pas assez cher, mon frère !!!
Posté par One . Évalué à 10.
Je crois qu'il faut développer ce type de démarche : Si Soft GPL vers Microsoft Alors Soft Payant. Cela serait un levier formidable pour financer des tas de projets GPL, destinés à la communauté du libre. Le seul problème est de savoir comment rédistribuer cette dime à l'ensemble des developpeurs (indépendants qui bouffent sur leur temps libre à vouloir changer la face du monde). Là, je pêche un peu, à méditer donc.
[^] # Re: Pas assez cher, mon frère !!!
Posté par WildChild . Évalué à 10.
[^] # CQFD
Posté par One . Évalué à 10.
"Ça pourrais être une option mais ca enlèverait complètement la place aux soft GPL sous Windows..."
Ben justement, c'est mon principal but en ce qui me concerne. Faire disparaitre l'idée que l'informatique sur PC est synonyme de Microsoft .
Bon quand bien même l'idée de noyer les softs propriétaires par des soft GPL est à la base une bonne stratégie à long terme, je suis farouchement opposé à ce concept. Utiliser du GPL sur des plateforme Microsoft implique l'achat (parfois forcé) d'une licence et donc renflouer un peu plus les bas de laine d' certain Mr G. Et cela ne m'enchante guère de savoir que mes programmes seront portés sous Microsoft. C'est mon point de vue.
Tu as remarqué que j'ai réussi à dire 3 fois "Microsoft" sans aucune déviation péjorative. suis-je à devenu un être sociable ?
[^] # Re: CQFD
Posté par WildChild . Évalué à 10.
Qu'est-ce que tu veux dire par là? Porté par Microsoft ou portés sur Windows? Et pourquoi ça t'enchantes pas? Si les programmes sont disponibles sur plusieurs plates forme on donne un accès à un plus grand public. Qu'on le veuille ou pas Windows fait partie du jeu et on doit s'y faire. Chaque OS à sa place même si certaines personne ne veulent l'admettre comme ce certain Mr. G.! Aussi, si Linux avait autant d'importance que Windows des problèmes du genre de ceux de Windows surviendraient probablement. Le choix final revient toujours à l'utilisateur et à l'utilisation qu'il fait de son PC.
Et pour ce qui est de l'achat de licences pour faire des soft GPL t'es pas obligé d'acheter les versions Professionnelles ou Entreprise des outils de développement. Souvent il existe des version personnelles (C++ Builder Personal Edition, Delphi Personal Edition, Borland C++ Free Compiler) qui sont généralement gratuits où à des prix assez bas. Dans le monde de la programmation il n'y a pas que Visual Studio et toute la gamique de MS.
[^] # Re: CQFD
Posté par One . Évalué à 10.
Pour répondre à ta deuxième question, crois tu être vraiment honnête en disant que l'utilisateur est libre de son choix, en matière de Système d'exploitation dans les entreprises ou ailleurs ? Cite moi un seul magasin vendant une linux-box prête à "rulez". Je pense pas que tu vas trouvé, pas en France en tout cas et surtout si la machine est destinée à ce "grand public".
Pas de GPL dans un monde fermé, car antinomique. Les tenants du propritaire ne veulent pas que le concept du GPL vive, alors pourquoi alimenter leur plateforme avec du GPL. Je pige pas trop.
[^] # Re: CQFD
Posté par WildChild . Évalué à 6.
Ici au Canada on peut faire monter des PC sur mesure par des petites boutiques (C'est probablement comme cela aussi en France). Si on se fait monter un PC on a le choix du OS qu'on veut mettre dessu. Il est certain que les grosses marques (Compaq, IBM, et j'en passes) viennent à la base avec Windows.
Pas de GPL dans un monde fermé, car antinomique. Les tenants du propritaire ne veulent pas que le concept du GPL vive, alors pourquoi alimenter leur plateforme avec du GPL. Je pige pas trop.
Si on arrête de faire des logiciels GPL sous Windows, ca serais un signe que les grosses entreprises auraient gagné. Il est certain que chacun à sa place alors pourquoi éliminer les programmes GPL sous Windows ou éliminer les logiciels propriétaires?
[^] # IF (MFC != QT) AND (OPENED != CLOSED) THEN ...
Posté par One . Évalué à 2.
Qu'avons nous à gagner dans cette histoire en fournissant du GPL à des users pro-closed, qui de toutes les façons ne changeront jamais de système d'exploitation ?
A part, peut-être l'intérêt de montrer que le monde du libre comporte des outils si extraordinaires que le portage des applis en est grandement facilité, sinon je vois toujours pas.
Attention, loin de moi l'esprit d'un linuxien fanatique qui dédaignent les utilisateurs des OS fermés. Je dis simplement que chacun doit aller au bout de sa propre logique. L'un utilise et fait la promotion de l'open-source en y apportant parfois des améliorations, l'autre achete et attend le bon vouloir d'un éditeur.
Mais bon, je crois que nous conmmencons à nous éloigner du sujet (Attention aux -1000 pts). Pour en revenir à l'article, il ressort en définitif, qu'il est quand même plus agréable de travailler avec des outils que l'on maitrise complètement, car mieux documentés et ça c'est la force de l'Open-Source.
Mes amitiés au Canada.
[^] # non !
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ce genre de personnes utilisent Gimp pour Windows parce que cela marche bien et peut même peut-être apprendre ce qu'est le libre. Et le jour où il aurra marre des BSOD, il testera linux.
C'est impossible de "forcer" un non informaticien à faire le grand saut du jour au lendemain. Il y a trop de chose nouvelles à apprendre. Une entreprise ne peut faire le grand saut d'un coup. Elle doit gérer le passé et ses utilisateurs !
nicO
"La première sécurité est la liberté"
[^] # Les gens qui se fichent de la philosophie du libre
Posté par frecillia5 . Évalué à 0.
[^] # Re: non !
Posté par One . Évalué à 0.
La deuxième partie souligne bien la question de fond, quant à l'intérêt de porter des LL sous des OS proprio C'est impossible de "forcer" un non informaticien...Elle doit gérer le passé et ses utilisateurs !. Je crois que les gens de l'open-source devraient plus se concentrer à faire de bons logiciels (comme il a été démontré dans l'article Qt versus MFC) et laisser ces softs uniquement sous GNU/Linux. Cela rendrait notre tux beaucoup attratif, car soft équivalent non présent dans l'autre camp. Quel meilleur moyen pour en faire la promotion, et son adoption par le reste du monde.
Mais bon, faut pas se leurrer non plus, la réalité économique est telle, que le seul moyen de financer les LL est de vendre du LL à la sauce marchande (tres chero !) pour les plateformes proprio. Et en fait cela ne me géne pas outre mesure, tant qu'il n'y a pas la même pratique sous les OS ouverts ou alors à moindre coûts.
Je suis persuadé que GNU/Linux serait sur tous les bureaux aujourd'hui, si on ne s'etait à ingénier à porter des applis bureautiques ou web (issus du libre) vers l'autre "truc là" (ok -1. car mon doigt à glisser). Il suffit de constater le succes du tux dans le monde de l'infographie.
Ne me parle surtout pas de Cygwin, qui pour moi, est plus un anti-linux que la promotion des outils GPL. Simuler un environnement unix sur du Microsoft, quelle belle connerie !!!
[^] # licence
Posté par Erwan . Évalué à 10.
On paye si on veut faire du logiciel proprietaire mais pour le GPL (ou compatible) c'est gratuit.
[^] # Re: licence
Posté par WildChild . Évalué à 10.
[^] # Re: Du vécu !
Posté par blackshack . Évalué à 3.
[^] # Re: Du vécu !
Posté par One . Évalué à 1.
Suis-je Hors débat ?
[^] # Re: Du vécu !
Posté par blackshack . Évalué à 3.
D'ailleurs depuis que je suis là il y a des machines sous nux -pas que la mienne- de plus les nouveaux serveurs de stockage et autres -Dell- tourne sous redhat
[^] # Re: Du vécu !
Posté par Guillaume Morin . Évalué à 3.
C'est sur que c'est une argumentation solide en faveur du LL, mais d'un autre côté, pour quelqu'un comme moi qui ne connait rien ni à Qt ni aux MFC, ça parait franchement peu objectif, même si fondamentalement ça me plait. En fait ça me fait l'effet d'une pub pour Kro$oft : on aimerais y croire, mais on sais qu'on va désenchanter.
N'ayons pas peur des mots : je soupconne l'auteur d'être plus ou moins hostile à l'idée de travailler avec des produits Microsoft. :)
[^] # Re: Du vécu !
Posté par One . Évalué à 2.
>>C'est sur que c'est une argumentation solide en faveur du LL
<Merite -1>
Et en plus tu nous donnes le site de LL. Cool mon gars et à quand l'install party avec leurs contributions ? Si en plus c'est open-bar, là je signe tout de suite. :))
</Merite -1>
>>N'ayons pas peur des mots : je soupconne l'auteur d'être plus ou moins hostile à l'idée de travailler avec des produits Microsoft. :)
Plus serieux, avoue tout de même que la probabilité de laisser un nom pour la postérité est plus grande dans le LL qu'avec des produits proprio où seul la mention de la boite est définie. Tu en connais toi des developpeurs de Microsoft ?
Combien de temps pour une livraison sur Paris ?
[^] # Re: Du vécu !
Posté par Guillaume Morin . Évalué à 2.
Pour ceux qui ne comprennent rien : LL veut dire à la fois Lejay Lagoute, là ou que j'bosse, et aussi Logiciel Libre, vous savez, le truc de Stallman. :)
>>Tu en connais toi des developpeurs de Microsoft ?
Heu... Bill Gates? J'ai bon?
Sans déconner il y a quelques mois j'ai vu, tout comme beaucoup d'entre nous je pense, un reportage sur des ex-codeurs de Kro$oft, et franchement ça m'a fait flipper: les mecs millionnaires à la retraite à 30 ans. Argh!! Y'en avais même un qui ne pouvais plus taper une ligne de code, il en avait la phobie! RMS protèges-moi de ces démons!
[^] # Re: Du vécu !
Posté par frecillia5 . Évalué à 1.
Les sous c'est surtout pour que Trolltech gagne un maximum de pognon (je ne leur repproche pas, c'est bien naturel), et pour payer les mecs qui bossent sur QT ... c'est justement à cause de cet argent que le portage de Qt sous Windows est n'en est pas encore au stade expérimental comme celui de GTK
Tout est mis en oeuvre pour encourager les développements de type GLP
Je dirais plutôt tout est mis en oeuvre pour faire connaître le produit en l'offrant gratuitement à ceux qui ne l'auraient de toute façon pas acheté.
Par ailleurs comme Trolltech se doutent bien qu'aucune boite ne devoppera jamais sous GPL, ça leur assure de gagner quand même des sous (c'est clair qu'il serait bien emm... si leurs clients passaient sous GPL pour ne pas payer la license QT)
le monde selon Microsoft doit être un monde de licences
Ou est le rapport avec MS ?
Tu crois vraiment que les gens qui utilisent QT pour développer des soft sous UNIX, ils bossent gratuitement et qu'ils font cadeau de leur soft avec un ruban marqué GPL ?
pour des questions de "secret defense"
Pour des questions d'image tu ne file jamais le source à un client sauf si il t'y oblige avec un couteau sous la gorge.
[^] # Alors, où ai-je faux ?
Posté par One . Évalué à 1.
Enfin, la tendance d'aujourd'hui est que, les boites sensées faire du code fermé, se sont aperçu de la viabilité du modèle "open-source" quant à l'évolution d'un produit :" Le mettre en open-source et profiter de la formidable force de la communauté". Tout le monde est gagnant. Alors que Trolltech gagne de l'argent, bof cela ne me gène pas, tant que l'accès aux sources est garantie.
Ou est le rapport avec MS ?
Si tu vois pas, je peux plus faire grand chose pour toi. Tout a été dit dans l'article dont on est sensé parlé ici :).
Amicalement.
# Interressant...
Posté par tene . Évalué à 10.
- la finesse de MFC pour ce qui concerne la gestion fenêtre/GDI est un défaut, en ce qui concerne l'approche objet... mais cela rend MFC relativement rapide et léger (dans un CWnd la classe de base englobant les fenêtre, presque toutes les méthodes sont inlines), qu'en est-il des performances de QT? Je n'ai pas vu tourner d'application Qt sous Win32, sous nux, c'tait des app KDE, plutôt lente, quelqu'un aurait des exemples (compilés)?
- Tu parles du modèle doc/view, tout d'abord, il est parfaitement évitable (par défaut dans le cas d'une application basé sur une boite de dialogue, MFC ne crée rien en rapport avec doc/view) Ensuite qu'est ce que QT propose dans ce domaine? (serialization, gestion MDI, vue multiple, etc...)
- Je suis également surpris, quand tu parles de CString/QString, as-tu regarder le CString de VS.NET?
Il m'a semblé qu'ils ont (enfin) nettoyé leur bordel.
Enfin voilà, pour conclure, je me demande juste si MFC et QT joue bien dans la même cours...
[^] # Re: Interressant...
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 6.
[^] # Re: Interressant...
Posté par Philippe F (site web personnel) . Évalué à 7.
> je me dis: en effet, ça peut faire gagner du temps...
Quand on connait bien un systeme, (que ce soit un langage, une bibliotheque ou un OS), on a toujours du mal a changer ou a evaluer ses faiblesses. Je t'encourage a downloader la version d'evaluation et a lire le tutorial. En quelques heures, tu pourras faire une application Qt. Tu te feras ainsi ton idee par toi-meme.
La plus grosse difference, c'est que Qt est simple a faire marcher. Pas besoin de comprendre des trucs complique, ca marche juste.
> qu'en est-il des performances de QT?
Je n'ai jamais note aucun probleme.
> Je n'ai pas vu tourner d'application Qt sous Win32,
Je me repete, telecharge leur version d'evaluation et joue un peu avec. Si tu veux, je peux meme te les envoyer.
> Tu parles du modèle doc/view, tout d'abord, il est parfaitement évitable
Ce n'est pas mon experience. Tout dans les MFC est base sur du doc/vue. A part en effet les boites de dialogues. Mais ce sont des boites de dialogue, non des application ? Ca ne me serait pas venu a l'idee de construire une application sur une boite de dialogue.
> Ensuite qu'est ce que QT propose dans ce domaine? (serialization, gestion MDI, vue multiple, etc...)
Je ne suis pas sur de comprendre bien la question mais je vais essayer de repondre. Le mecanisme de base de Qt, les signaux et les slots permettent une souplesse incroyable dans l'architecture. Cela permet de gerer sans probleme un doc/vue, des vues multiples, des MDI, ... Tu fais en fait ce dont tu as envie.
> Je suis également surpris, quand tu parles de CString/QString, as-tu regarder le CString de VS.NET?
Non, ma comparaison portait sur les MFC pure. Il parait qu'il y a des MFC 7.0 maintenant. Tres bien pour eux, moi je reste a Qt.
[^] # Re: Interressant...
Posté par Philippe F (site web personnel) . Évalué à 4.
J'ai laisse passer celui-la: bien sur qu'ils jouent dans la meme cour. Le but, c'est de produire une application avec des controles, sous Windows. Qt et les MFC permettent tous les deux d'obtenir ca.
[^] # Re: Interressant...
Posté par tene . Évalué à 10.
C'est fait (évidemment ;-), je testerai cela après le boulot!
Cependant, je rajoute quand même quelques précisions sur mes questions:
- les performances: je n'ai pas vu d'application tourné sous Qt, et j'aimerais en voir, je ne parle pas d'un petit exemple, mais d'une "vraie" application.
Bcp de "technologie" sont bluffantes dans les exemples et moins jolie une fois qu'on passe à la réalité (GDI+, DirectX, opengl, etc... si on se limite au graphisme, sont très simple à aborder, mais obtenir un truc réellement performant, demande beaucoup de travail... )
Enfin la question de gestion doc/view, serialization, etc...
Serialization: la base, En MFC tu as une série de conteneur plus ou moins générique: ils sont perfectible, mais ont un avantage: ils sont serializable et serialize leur contenu, pour cela il suffit d'implémenter une ou deux méthodes dans chaque classe. Je n'ai pas trouvé de classe de base serializable commune à tous Qt, faut dire je n'ai fait que passer en vitesse... et réécrire cela pour une application prend du temps...
La gestion MDI de MFC est évidemment reproductible, mais le fait que les MFC offrent d'emblé un framework cohérent et souple pour le faire permet de gagner du temps (30 secondes pour avoir une app de base multi-document, multi-view...).
Le fait d'avoir ou pas cela en QT permettra de gagner ou non un temps précieux (qui sera peut-être perdu avec MFC dans d'autre partie de l'application). En java par exemple rien n'est réellement prévu pour, je me retrouve alors à "ramer" pour avoir une bête application SDI cohérente, la gestion des barres d'outils et des menus est un cauchemar (comparé à ce que je connais en MFC). D'où ma question...
Enfin voilà, je testerai un peu avec Qt dès que j'aurai un peu de temps, l'idée d'avoir quelques choses multi-plateforme me plait assez en fait...
Et finalement:
J'ai laisse passer celui-la: bien sur qu'ils jouent dans la meme cour. Le but, c'est de produire une application avec des controles, sous Windows. Qt et les MFC permettent tous les deux d'obtenir ca.
MFC permet beaucoup plus que cela, c'est plus un framework pour applications qu'un framework d'interface graphique, il apporte son lot de contrainte ainsi que ces quelques solutions. SI QT ne propose pas de classes pour gérer le doc/view, aucune solution pour le MDI, pas de serialization, etc. alors MFC est quelque chose d'assez différent de QT, cela ne diminue en rien la qualité de QT, mais cela biaise un peu le débat, on se retrouve à comparer deux choses différentes en ne tenant pas compte de leur différences.
Sous Windows, ce qui permet d'avoir des applications avec contrôle, c'est Win32 (les "widget" MFC sont des contrôle windows, MFC ne fait QUE layer objet entre les deux, il n'implémente pas (plus) grand chose de graphique). Si tu utilises MFC pour avoir des classes au lieu de handle, ce n'est à mon avis pas la bonne idée (y'a mieux...), si tu pars du principe que MFC va te permettre d'avoir un ensemble cohérent entre les données de ton app, le feedback graphique et l'utilisateur, alors tu y es... mais est-ce bien le but de QT? (KDE n'ajoute-t-il pas son lot de classe qui prenne en charge ce que QT ne fait pas?).
[^] # Re: Interressant...
Posté par blackshack . Évalué à 5.
http://www.trolltech.com/products/success/index.html?cr=0(...)
c un lien sur le site de trolltech qui pointent sur diverses applis de boites utilisant qt cela te donnera des idées
[^] # Re: Interressant...
Posté par Philippe F (site web personnel) . Évalué à 4.
> Serialisation
A quoi ca sert ? Je ne vois pas trop. Il me semble que tous les types de Qt peuvent passer dans un QIODevice donc il y a des chances que tout Qt soit serialisable. Mais c'est a verifier.
> MDI
Qt a une class QWorkSpace qui te permet d'avoir des fenetres dans un espace de travail. Combine avec QDockWidget, tu peux facilement reecrire visual C++. Il y a un exemple qui s'appelle MDI.
Je n'ai pas beaucoup l'experience des applis MDI mais ca me parait bien pris en compte.
Pour la suite, j'ai du mal a suivre. Le but de Qt, c'est de faire des applications.
Ce que KDE rajoute, c'est une coherence et une communication entre les applications et le bureau.
Je suis interesse par tes impresssions a chaud sur Qt quand tu l'essayera. Envois-moi un mail: pfremy [at] kde [dot] org
[^] # Re: Interressant...
Posté par Aurelien Gateau (site web personnel) . Évalué à 4.
http://www.globecom.se/tora/(...)
[^] # TORA
Posté par frecillia5 . Évalué à 1.
[^] # Exemple d'appli Qt sous Windows: PSI
Posté par Erwan . Évalué à 2.
http://psi.affinix.com/(...)
Tu as aussi Qt Designer, le logiciel de developpement rapide inclus dans la distrib Qt.
[^] # Re: Interressant...
Posté par Infernal Quack (site web personnel) . Évalué à 4.
Et puis regardes Opera et tu verras si il n'est pas rapide. Il bat à l'aise Mozilla et Konqui sur pas mal de pages.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Interressant...
Posté par Pierre Tramo (site web personnel) . Évalué à -1.
La derniere fois que j'ai fait le test, c'était l'inverse, rare était les pages plus lentes sous mozilla.
Et puis, il faudrait plutot comparer mozilla qt(mais qui n'est plus dévelloppé) avec mozilla et les autres toolkits.
[^] # Re: Interressant...
Posté par Philippe F (site web personnel) . Évalué à -5.
-1 parce que rien a voir
[^] # Re: Interressant...
Posté par kangs . Évalué à 3.
en dernier ressort, mais sinon dans QT les class de
bases possèdent beaucoups de fonctions inline alors
que les widgets + complet en ont très peu. Les inlines
peuvent avoir l'inconvénient de créer beaucoups de dépendances
et donc augementer le temps de compile (Je sais ce n'est pas
forcément un argument valable).
Pour les performances trolltech a fait des comparaisons
disponibles sur leur site, les méchanismes SIGNAL/SLOT sont
moins performants que les callback traditionnelles (pointeurs)
mais la différence paraît vraiment mineure pour des applications
orientées utilisateurs (interfaces, masques, ...).
>Enfin voilà, pour conclure, je me demande juste si MFC et QT joue bien dans la même cours...
Non, MFC avait bonne réputation début 90, mais est
aujourd'hui largement dépassé.
[^] # Oh le méchant FUD
Posté par frecillia5 . Évalué à -2.
Tu ne peux nous expliquer sur quoi tu base cette affirmation péremptoire ?
Si c'est le coup de .NET, tu n'a rien compris .NET c'est pour que MS puisse manger des parts de marché aux fabricants de serveurs d'applications (en gros BEA avec Weblogic et IBM avec WebSphere).
Dans le même genre j'ai aussi "Avec l'arrivé de Websphere sous Linux, GTK/QT/LessTif est aujourd'hui largement dépassé". ça marche aussi avec PHP 4.
Bon que les commerciaux d'une boite (pas que MS qui fait ça mais TOUTES les boites) essayent de démolir un concurrent, c'est de bonne guerre : il faut bien qu'ils défendent leur gagne pain. Par contre, raconter n'importe quoi bénévolement ...
[^] # Re: Oh le méchant FUD
Posté par pasBill pasGates . Évalué à 1.
Moi j'en connais un qui va etre tres surpris...
[^] # Re: Oh le méchant FUD
Posté par frecillia5 . Évalué à 0.
# Et wxWindows ?
Posté par Yannick (site web personnel) . Évalué à 0.
[^] # Re: Et wxWindows ?
Posté par Sébastien HEITZMANN . Évalué à 1.
# A nuancer
Posté par 7la . Évalué à 10.
je bosse avec les mfc depuis à peine 2 ans, mais déjà je releve quelques erreurs dans l'article :
- avoir des vues différentes dans un controle à onglets ne demande guere plus d'une demi heure de boulot pour peu qu'on sache se servir d'un moteur de recherche.
- le chevauchement des identifiants de ressource dans les dll ne pose aucun probleme à partir du moment où l'on a compris comment sont chargées les ressources ( voir AfxSetResourceHandle si besoin de precision ).
Ensuite restent certains points discutables ( architecture doc/view contournable, msdn bourré d'exemples, programmes qui ne plantent pas à partir du moment où l'on code proprement ) et des vérités indéniables ( au moins sur les MFC, pour Qt, j'en sais rien).
A part ca l'article donne assez envie de jeter un coup d'oeil à Qt, donc finalement c'est un happy end.
[^] # Re: A nuancer
Posté par kangs . Évalué à 2.
moment où l'on code proprement ) et des vérités indéniables ( au moins sur les MFC, pour Qt, j'en sais rien).
Je pense qu'il voulait mettre en évidence des contraintes 'bizarres' avec le MFC et
que QT de par ca conception ne possèdent pas ces inconvenients et est plus intuitif.
# Ca doit etre la langue
Posté par Philippe F (site web personnel) . Évalué à 4.
L'anglais doit moins bien passer que le francais.
[^] # Re: Ca doit etre la langue
Posté par Infernal Quack (site web personnel) . Évalué à -1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Ca doit etre la langue
Posté par oliv . Évalué à 2.
Bref, depuis la création d'advogato ou kuroshin et autres, Slashdot n'a aucun intérêt...
-1 car avis perso hors sujet :)
[^] # Re: Ca doit etre la langue
Posté par Jean-Yves B. . Évalué à 5.
En fait, tu fais un comparo Qt/MFC et il y en a qui ont pris ça comme un comparo MFC vs le reste du monde en supposant que tu ne jugeais que Qt digne d'être mentionné.
Bref, c'est la slashdot crowd habituelle, avec toujours les même 99% de commentaires trollesques, hors-sujet ou complètement sans intérêt. C'est l'effet de masse qui veut ça, je suppose.
# perso ...
Posté par kesako . Évalué à 10.
Les MFC on peut s'en accomoder meme si on est convaicu que c'est de la m... Par contre comme le dit l'article, on ne peut rien faire sans l'env de dev de MS. Sur le court terme il permet d'aller vite mais sur le long terme ... Ceux qui comme moi on dû reprendre des applis developpées en 1997 ou 1998 avec VC++ 4 ou 5 avec le VC++6 actuel comprendront ce que je veux dire. Si ca marche tant mieux, sinon ... S'il faut melanger les differents objets com, Dcom, activX, ... c'est l'enfer.
Alors que sur unix les makefiles produits en 1990 sont toujours valables.
On peut peut faire un gros progamme QT ou Gtk sans env de dev , ce n'est pas trop dur.
KDevelop cree des projets avec tout ce qu'il faut pour compiler sur une ligne de commande (configure, autoconf,...)
Alors que vous de pouvez pas faire confiance au makefile generé par VC++ ( je parle d'experience)
J'ai vu de mes yeux de bons programeurs faire de merveilleux programmes avec VC++ et d'autres (debutants ou non) produire d'affreux fatras immaintenable. Ca arrive aussi sur unix mais moins souvent car vous avez tout le code sous les yeux et pas seulement la fonction correspondant au bouton cree a la souris ( j'ai deja vu des fonctions OK_Button de 800 ou 1000 lignes !!!)
Bref je ne jete pas la pierre a MS , ils ont ete oblige de rajouter des couches par dessus des couches sans jamais pouvoir tout remetre a plat, mais je dis simplement que c'est tres domage pour tout le monde, ca empoisone la vie des developpeurs. Ce qui devrait etre un plaisir devient une corvee
[^] # Re: perso ...
Posté par Dawm . Évalué à 2.
Maintenant si le programmeur est compétent et désire développer pour plusieurs plateformes et/ou en dév collaboratif, il va essaier d'écrire du code plus standard, ou au moins plusieurs versions avec des #define, sinon c'est qu'il ne sait pas programmer.
[^] # Re: perso ...
Posté par kesako . Évalué à 5.
tu m'a mal lu.
Je ne parle meme pas de ca. Je parle de dev et de maintenance sur le moyen terme 2-4 ans.
Meme avec un simple soft prevu uniquement pour windows, comme tu ne peux pas developer sans Visual studio (a cause de MFC entre autres) si dans 2-3 ans on te demande une nouvelle fonctionnalite ou de corriger un bug, et si le VStudio actuel est "tres legerement" incompatible avec celui qui a servi a l'origine , c'est la galere la plus totale... Au lieu de 10' de boulot, tu y passe la journee voire la semaine s'il de faut reconfiguerer une machine avec un vieux VC++.
Et le pire c'est que la plus part du temps tu ne sais pas pourquoi ca marche ou pas !
Une situation extrement rare sur unix.
[^] # Re: perso ...
Posté par Dawm . Évalué à 0.
[^] # Visual studio & MFC
Posté par frecillia5 . Évalué à 1.
Par exemple, tu aura des CString dans le code de l'interface et du std::string ailleurs.
De la même manière, tu n'aurais par intérêt à mettre des QString partout dans ton code même si c'est plus portable (mais pas autant que la STL).
[^] # Re: Visual studio & MFC
Posté par Philippe F (site web personnel) . Évalué à 2.
> même si c'est plus portable (mais pas autant que la STL).
En fait, les QString sont plus portables que la STL. Une des raisons pour lesquelles Qt a redefini tout un tas de conteneurs (QString, QList, ...), c'est que les STL etaient mal supportees par la plupart des compilateurs.
Quand tu vois le nombre d'architecture supporte par Qt, c'est impressionnant.
C'etait surtout vrai au temps de Qt 1. Maintenant que les STL sont de mieux en mieux supportes, Trolltech a fait en sorte que les conteneurs de Qt soient compatibles. Mais il reste encore des compilateurs ou la STL n'est pas une option.
[^] # Re: Visual studio & MFC
Posté par frecillia5 . Évalué à 1.
Si ton compilo est buggé il faut changer de compilo.
# et .NET ?
Posté par Matthieu Nicolescu . Évalué à -1.
Moi ce que j'aimerai bien voir par exemple c'est un comparatif Windows Application .NET et QT. A mon avis danc ce cas, .NET aura plus de répondant que MFC !!!
zz
# et borland ?
Posté par farib . Évalué à -3.
borland prévoit, masi quand on ne sait pas (en tout cas ils le laissent entendre) faire uen version de builder sous nux
c pour ca qu'ils ont introduit la clx, paske la vcl était spec windows
[^] # Re: et borland ?
Posté par Aurelien Gateau (site web personnel) . Évalué à 5.
[^] # Re: et borland ?
Posté par farib . Évalué à -2.
[^] # Re: et borland ?
Posté par Sylvain Rampacek (site web personnel) . Évalué à 4.
Mais je crois que ça ne devrait pas tarder, je me souviens d'avoir entendu fin de l'année ou début de l'année prochaine... (en plus, ça correspond au laps de temps entre Delphi et C++Builder).
Petite précision, la CLX est en Pascal Objet, tout comme la VCL. C++Builder se contente d'utiliser un générateur de *.h et du compilateur Delphi pour construire des applis VCL... Donc je suppose que pour la version de C++Builder utilisant la CLX, ce sera le même principe...
[^] # et gtk ? et tk ? et GnuStep ? et ma soeur ?
Posté par Erwan . Évalué à 0.
[^] # Re: et gtk ? et tk ? et GnuStep ? et ma soeur ?
Posté par Matthieu Nicolescu . Évalué à 3.
Donc voila je me disais que cet article avait peut être quelques mois de retard...
[^] # Re: et gtk ? et tk ? et GnuStep ? et ma soeur ?
Posté par Dawm . Évalué à 5.
[^] # Re: et gtk ? et tk ? et GnuStep ? et ma soeur ?
Posté par Matthieu Nicolescu . Évalué à 3.
>>"Faut pas oublier que .Net est loin d'avoir >>emporté l'adhésion pour le moment chez les >>développeurs"
C'est un peu normal sachant que le framework .NET version stable est sorti il y a de cela 6 ou 7 mois...
Mais bon il est clair que .NET sera la référence pour développer windows ! On pourra vérifier ca dans un an...
# Linuxfr = Site D'intégriste !!!!!
Posté par Matthieu Nicolescu . Évalué à 3.
Par exemple la semaine dernière,un article est paru disant que la norvege dépensait plus de 6.8 M d'euro pour les nouvelles techno et comme par magie sur votre site "nouvelle techno" a été remplacé par Microsoft !!! On pouvait alors lire que la norvège devait dépenser 6.8 M d'euro pour licenses microsoft !! un comble !!
Sinon pour l'article QT vs MFC, lorsqu'il ya des commentaires intéressant mais n'allant pas forcément dans l'esprit des intégriste binaire (Microsft ca sux Open source powaa),il sont tout de suite mal noté !
Soyez moins .... les gars !
[^] # Re: Linuxfr = Site D'intégriste !!!!!
Posté par Infernal Quack (site web personnel) . Évalué à 1.
Tout est bon dans le cochon :)
PS : Oh mais je suis pontife \o/ oué !!!
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Linuxfr = Site D'intégriste !!!!!
Posté par Matthieu Nicolescu . Évalué à -1.
Ce qui m'embête un peu plus (pour la crédiblité du site car je suis un habitué) c'est que les modérateurs de linuxfr laisse passer des news infondées ! (voir mon message précedent sur les licenses micro$oft)
zz
[^] # Re: Linuxfr = Site D'intégriste !!!!!
Posté par Franck Yvonnet . Évalué à 1.
[^] # Re: Linuxfr = Site D'intégriste !!!!!
Posté par Dawm . Évalué à 1.
[^] # Re: Linuxfr = Site D'intégriste !!!!!
Posté par Infernal Quack (site web personnel) . Évalué à 5.
Je répartie moi monsieur.
Soit j'ai moins de -10 ou plus de +10 sinon c'est que mon commentaire était inintérèssant.
Regardes le post sur KDE Myth ou je dis un truc supra-intérèssant. Je cite : "Faut mettre de l'anti-mythe sur les applications KDE" et bien j'ai eu un truc comme +30
Non monsieur, moi je fais de la qualité.
Soit du 100% pur troll,
soit du 100% blague de moules,
soit du 100% intérèssant (si si je vous jures un jour j'en ai posté un comme-ça)
hop -999 (Faut bien que je puisse relire mon post ;)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# Qt et cross-compiling
Posté par tanguy_k (site web personnel) . Évalué à 2.
Sachant que Visual (pour Borland je sais pas) est une merde immonde pour le C++ (il gère mal les for, les templates, les namespaces, les warnings sont pitoyables ect...)
serait-il possible de faire du cross-compiling avec mingw ou cygwin et ainsi d'utiliser g++ ?
En ce moment, j'utilise gtk sous unix et windows avec mingw.
evidemment gtk en C++ c'est la lutte, mais le cross-compiling c'est vraiment que du bonheur !
si c'est possible de faire ca avec Qt ca m'interesse beaucoup !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.