Discussion :

[TheGzD]

salut , c'est la licence open source (LGPL 2.1) qui change mais qt sera toujours payant pour une application commerciale

ta phrase se paradoxale étant donné que l'intérêt du passage de GPL à LGPL permet justement l'intégration de la librairie gratuite à des solution payantes.
Après libre à toi d'opter pour une solution payante si tu veux disposer de plus de service (logiciels ou humains) ou si tu ne comptes pas être obligé de rendre publique ton code (en cas d'une non-utilisation dynamique de la librairie libre).

[farscape]

mais elle m'oblige a fournir mes sources avec le programme construit non ?
si c'est le cas ce n'est pas d'un grand intérêt pour moi.

[TheGzD]

Sauf si tu l'utilises dynamiquement (via une dll par exemple).

Edit : voici le post du forum où l'annonce est commentée http://www.developpez.net/forums/d67...-licence-lgpl/ tu devrais y trouver de façon plus détaillée ce que je veux dire.

[le petit dernier]

je me demandais si avec l'arrivée de Seven <Microsoft ne prévoyait pas une réactualisation des MFC(Designer, RegExp,StyleSheets,etc).

Car Qt prend vraiment beaucoup d'avance sur tout un tas de nouvelles technologies.

Si quelqu'un a une info....

Cordialement

[TheGzD]

Je pense que tu devrais trouver les infos que tu cherches ici.

[Gabrielly]

je me demandais si avec l'arrivée de Seven <Microsoft ne prévoyait pas une réactualisation des MFC(Designer, RegExp,StyleSheets,etc).

Car Qt prend vraiment beaucoup d'avance sur tout un tas de nouvelles technologies.

Si quelqu'un a une info....

Cordialement

Il s'agit de ton opinion personnel.

Les MFC ont subit une grande évolution avec le Feature Pack et je ne vois rien à envier à QT. Et d'ailleurs les MFC sont plus mature que QT, les MFC sont plus répandues que QT et en milieu professionnel c'est MFC et donc Visual qui est réclamé.

L'architecture des MFC est vraiment impéccable pour moi avec son modèle document-vue et avec toutes les nouvelles technologies des interfaces utilisateurs modernes.
Cette dernière introduit la personnalisation de nos classes tels que les fénêtres auto-glissante (dockable pane), les tab controls, la prise en charge par un gestionnaire de panneaux pour lequel on personnalise le mode d'encrage.

Les MFC introduit de nouvelle feuille de propriétés CMFCPropertySheet et page de propriétés avec sur le panneau droit un style en page tab, toolbar button (outlook), tree control node, ou list item.

Les MFC prennent en charge la personnalisation du clavier et de la souris.

Elle donne la possibilité d'introduire dans son application des outils définis par l'utilisateur. En d'autres termes dintégrer d'autres applications tierces comme faisant parti intégrante de ton application de base.Les User-defined tools

Est-ce que QT prend en charge les MDI Tabbed Groups. Les utilisateurs de Visual Studio en ont l'expérience.

A ce que je sache il n'y a aucun support du rubban d'office dans QT non?
Quelle est l'équivalent de cette classe CMFCRibbonBar Class?

Et pour ce qui est de la recherche du style dans une application parle t-on d'un Visual Manager qui nous en facile la gestion sans oublier que l'on peut le personnaliser à notre gout en surchargeant les soit-disant DrawItem() des classes du Visual Manager?

[le petit dernier]

Merci bien à TheGzD pour le lien.

Une semaine de programmation avec Qt suffit à comprendre que les mfc ne sont qu'un vieux dinosaure auquel on a rajouté de multiples couches de peintures pour tenter de suivre les évolutions en cours.

Et pourtant je programme avec et même je les aime les MFC mais elles ne sont hélas pas à mettre entre toutes les mains sous peine de désillusions douloureuses.

A un programmeur c++(qui se fait de plus en plus rare) je ne conseillerais pas
de commencer par les MFC.

le langage c++ est un langage pénible car très(trop) copieux et plein de zones obscures à éviter.

Si en plus de plusieurs années d'apprentissage du c++,il doit se coltiner plusieurs années de MFC alors d'animal rare il se transformera en bête en voie de disparition.

Cordialement

Quand je pense que le gdi+ doit être intégré à la main par le programmeur
alors qu'une option dans le wizard suffirait.... et tout est comme ça avec les MFC

[Gabrielly]

Merci de nous partager ton expérience.

[superjaja]

Je suis tout a fait d'accord avec le petit dernier je travaille avec les MFC et il est vrai que l'on sent que l'API date et a beacoup de lourdeur. Cependant tu as raison Gabrielly, le Feature Pack est quand meme une bonne avancé cependant on est encore loin des standards actuels, API JAVA, Qt, .Net.
A un moment j'avais cru entendre que MS devait refaire une API pour le C++ est ce que quelqu'un a des infos ?

[Mat.M]

Merci bien à TheGzD pour le lien.

Une semaine de programmation avec Qt suffit à comprendre que les mfc ne sont qu'un vieux dinosaure auquel on a rajouté de multiples couches de peintures pour tenter de suivre les évolutions en cours.

non je ne suis pas d'accord je vais t'expliquer pourquoi :
oui les MFC c'est antédiluvien mais les projets que tu auras fait avec VC++4.0 ,VC++5.0 et VC++6.0 eh bien tu pourras toujours les reprendre avec VC++2008.
Voire...inversement parce que les MFC c'est la base..
Est-ce qu'avec Java,.NET tu peux faire la même chose ??
Non bien évidemment et je je parlerais pas des tas de boites qui ont développé avec VB6 et qui doivent mettre leurs projets à la poubelle pour passer à NET.
Alors qu'avec MFC comme cela n'évolue pas beaucoup et cela n'a aucune raison d'évoluer parce que par essence même c'est une mince couche au dessus des API tes projets VC++4.0 ,par exemple, tu peux toujours les exploiter..et tu pourras toujours les exploiter..

Je possède par exemple C++ Builder 4.0 et pas évident que la dernière version supporte la version de la VCL qui aille avec BCB4.0
Et que dire de .NET qui change sans arrêt ?
Dans 10 ans tes développements .NET tu n'auras plus qu'à les jetter alors qu'avec MFC ils seront pérennes...

le langage c++ est un langage pénible car très(trop) copieux et plein de zones obscures à éviter.

C'est un autre sujet mais il y en a long à dire dessus..
je programme depuis quelques mois avec C#/NET c'est pas forcément plus simple.
Par exemple avec MFC tu as CString::Left() qui te donne une occurence de la chaine de charactêres en partant de la gauche, en .NET pas d'équivalent j'ai perdu 30 minutes pour faire la même chose alors qu'avec MFC cela coule de source..mais bon c'est un autre sujet...
Copieux ? Cela reste à prouver ; fais un projet Java ou C#/NET versus C++ et MFC compte le nombre de lignes et tu me diras quel est celui qui comporte le plus de nombres de lignes...
Déjà que dans un programme en C# il faut charger tous les composants et controles en dynamique parce qu'il n'est pas possible de les lier en ressource..donc cela fait du code en plus

Quand je pense que le gdi+ doit être intégré à la main par le programmeur
alors qu'une option dans le wizard suffirait.... et tout est comme ça avec les MFC

Justement il faut que le gdi+ soit intégré à la main ! Si dans 10 ans le gdi+ n'existe plus ?
Il faut que les MFC soient indépendantes des évolutions et ne doivent conserver que la base de la programmation Windows.
Si tu veux des applis Look'n Feel il faut prendre .NET/ WPF à ce moment-là....
Mais dans quelques années tu jetteras ton développement à la poubelle

Merci bien à TheGzD pour le lien.
Une semaine de programmation avec Qt suffit à comprendre que les mfc ne sont qu'un vieux dinosaure

D'accord mais on en reparlera d'ici quelques temps....

est-ce que Qt résoud tous les cas de figures je ne suis pas certain..

[Mat.M]

L'architecture des MFC est vraiment impéccable pour moi avec son modèle document-vue et avec toutes les nouvelles technologies des interfaces utilisateurs modernes.

Absolument d'accord...
Est-ce que par exemple sous Qt il y a des ScrollView,CFormView etc..??
Je n'en suis pas si certain...
Avec Borland C++ Builder je m'étais arraché les cheveux de la tête pour faire certains trucs faciles avec MFC..

[superjaja]

D'accord mais on en reparlera d'ici quelques temps....
est-ce que Qt résoud tous les cas de figures je ne suis pas certain..

Chaque API a ses avantages et ses inconvenient et serieux je connaissais uniquement les MFC en C++ parce que c'est ce que j'utilise au boulot. J'ai testé Qt et c'est vraiment mieux fait dans l'ensemble. Cela a de plus comme avantage d'etre portable et licence LGPL maintenant. De toute façon comme tu le dis si bien toi meme le plus gros avantage pour les MFC c'est aussi sont plus gros inconvenient c'est que c'est un tres vieille API. Alors oui cela surement compatible avec les projet a venir mais a quelle prix. De meme on sait pas si un jour MS arrettera pas les MFC au profit du tout .Net qu'ils essayent de mettre beaucoup plus en avant.

[farscape]

Chaque API a ses avantages et ses inconvenient et serieux je connaissais uniquement les MFC en C++ parce que c'est ce que j'utilise au boulot. J'ai testé Qt et c'est vraiment mieux fait dans l'ensemble. Cela a de plus comme avantage d'etre portable et licence LGPL maintenant. De toute façon comme tu le dis si bien toi meme le plus gros avantage pour les MFC c'est aussi sont plus gros inconvenient c'est que c'est un tres vieille API. Alors oui cela surement compatible avec les projet a venir mais a quelle prix. De meme on sait pas si un jour MS arrettera pas les MFC au profit du tout .Net qu'ils essayent de mettre beaucoup plus en avant.

ça fait 10 ans que j'entends ça ...., a ce que j'ai pu voir et entendre dans les conférences techdays et discuté avec les personnes de chez MS ça n'a pas l'air d'être à l'ordre du jour, sinon je ne comprends pas trop l'intérêt d'avoir fait évoluer les MFC avec le service pack .
chez ms ils semblent avoir entériné qu'il a deux mondes: celui du C++ natif win32 et celui de .net avec des points de convergences grâce au C++/cli.
Visual 2010 viendra encore conforté cet état avec ses nouveautés tant au niveaux de nouvelles fonctionnalités MFC correspondant aux nouvelles api 32 de Seven, que par exemple la nouvelle bibliothèque PPL (Parallel Pattern Library ) pour le développement paralelle .
Encore un dernier point bcg vend un complement de bibliothèque pour les MFC qui complete celle de MS.
pour moi qui travaille dans le monde windows depuis le début le problème de la portabilité ne se pose pas.

[superjaja]

Je savais pas pour la bibli PPL je savais qu'il y avait un truc de prévu sur le framwork 4.0 pour une bibli paralelle mais pas pour les MFC. Je suis content de l'apprendre. Cela ressemblera a un truc genre TBB ?

[farscape]

c'est un peu différent même si l'on retrouve les mêmes principes de base.
un point important c'est l'utilisation des expressions lambda ,
plus d'infos ici :
http://msdn.microsoft.com/en-us/magazine/dd434652.aspx

[superjaja]

Merci farscape pour le lien et les infos.

[3DArchi]

Visual 2010 viendra encore conforté cet état avec ses nouveautés tant au niveaux de nouvelles fonctionnalités MFC correspondant aux nouvelles api 32 de Seven, que par exemple la nouvelle bibliothèque PPL (Parallel Pattern Library ) pour le développement paralelle .

As-tu des références sur ce que sera Visual 2010 (je n'arrive pas à trouver). On dirait qu'il va y avoir aussi des features C++0x de supporté. Je suis curieux de tout ça...

[farscape]

je ne retrouve plus l'article us, mais une référence sur le blog de eric vernier:
http://blogs.msdn.com/ericmitt/archi...-de-vc-10.aspx

[3DArchi]

C'est un peu le genre de ressources que j'arrive à dégoter : 3 paragraphes pour mettre l'eau à la bouche... Bon, après tout 2010 c'est dans pas très longtemps.

[farscape]

je vais essayer de retrouver les infos.