Posté par Dawm .
En réponse à la dépêche Qt contre MFC.
Évalué à 10.
Un article vraiment intéréssant, surtout que j'avais l'intention de me renseigner à propos de QT. Je donne ici mon avis en tant que développeur sous Win32 directement en API, je ne supporte pas les MFC aprés les avoir essayés.
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
# Article intéréssant...
Posté par Dawm . En réponse à la dépêche Qt contre MFC. É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