C++ MFC vs .NET?

Question

Mes collègues utilisent Visual Studio 2002 et utilisent le C++ MFC. Je développe en C#.

Il n'y a pas eu de problèmes auparavant, mais maintenant nos clients se demandent si nous devrions vraiment développer dans des environnements différents. Mes collègues pensent (bien sûr) que je devrais passer au C++ MFC. Je pense qu'ils peuvent utiliser .NET au lieu de MFC.

Est-il utile d'apprendre le MFC ? Cela semble un peu démodé, ou ai-je tort ? Quels sont les arguments pour et contre le .NET par rapport au MFC ?

Éditer :

Nous développons des systèmes de processus et des applications d'assistance pour l'industrie nucléaire. L'application principale est un émulateur qui émule un ancien système informatique et utilise C++/MFC. Il est très critique en termes de temps, peut-être que le cœur devrait toujours être en C++ natif. Mais l'interface utilisateur de l'émulateur et toutes les applications environnantes ne sont pas particulièrement critiques.

Y a-t-il une vraie raison de remplacer l'application MFC existante ?

Answer 1

J'ai utilisé à la fois MFC et Windows Forms de manière intensive pendant très longtemps. Je viens de l'industrie du jeu vidéo, j'ai donc dû écrire de nombreuses applications de bureau au fil des ans, et avant .net, MFC était extrêmement utile. Avant même cela, j'écrivais des outils en pur Win32.

MFC avait certainement ses bizarreries, mais dans l'ensemble, cela rendait la vie beaucoup plus facile. Il était très facile d'intégrer OpenGL et Direct3D dans des vues personnalisées, et une fois que vous aviez compris comment faire, écrire des contrôles personnalisés était un jeu d'enfant. Le meilleur de tout, c'est que je pouvais simplement coder en C++, qui était simplement mon langage de prédilection. De plus, j'ai trouvé MFC très efficace et réactif.

Peu à peu, MFC a commencé à bénéficier du support de bibliothèques externes de contrôle, en particulier des bibliothèques de docking/toolbar, de sorte que mes outils comme les visualiseurs de modèles 3D et les éditeurs de niveaux avaient tous l'air plutôt sympa.

La plupart des applications que j'ai écrites créaient l'interface utilisateur de manière programmative, donc l'outil de disposition de dialogue/fenêtre était plus que suffisant pour mes besoins.

MFC 9 est aussi assez cool, surtout avec la bibliothèque de contrôle/docking Ribbon que Microsoft a publiée dans le cadre du Feature Pack. Ainsi, le vieux chien a encore de beaux jours devant lui, c'est sûr! :)

Lorsque .net 1.0 est sorti, j'ai trouvé la transition assez facile, car il prenait en charge le C++ managé. Ce n'était pas beau, mais cela offrait une rampe d'accès relativement directe au framework .net. Mais le point de basculement pour moi est survenu lorsque j'ai commencé à écrire des outils qui nécessitaient davantage le concepteur de Windows Forms, autour de .net 2.0. J'ai décidé de recommencer et d'apprendre le C#, que j'ai adoré - même si je ne m'habituerai jamais au fait de ne pas avoir de delete() sans new() ;). J'ai ensuite commencé à écrire des contrôles utilisateur, trouvant toute l'expérience très agréable et simple. Le framework .net était énorme, bien supporté, et en général j'ai trouvé plus facile de tout faire en C#/.net. De plus, la compilation était super rapide, et la capacité de refactoriser dans Visual Studio était géniale.

La beauté de C#/.net est qu'il ne vous limite pas à écrire uniquement en code managé. Vous pouvez toujours utiliser du code non managé, si les performances sont un problème par exemple, ou si vous devez partager du code entre des plates-formes. Par exemple, mes bibliothèques mathématiques sont écrites en C/C++, que je mets dans des bibliothèques permettant à C# d'envelopper/utiliser le même code, même si ce n'est que temporaire. Je vais aussi porter ces bibliothèques en C# à un moment donné pour que tout soit en pur .net.

La dernière expérience que je souhaite mentionner est que j'ai passé les derniers mois loin de la programmation de jeux sur console, et j'ai passé du temps à programmer l'InterWeb. J'utilise la pile Microsoft, je programme en ASP.net/C#, et je dois dire que c'est très agréable, avec toute la connaissance du C# directement applicable. La seule courbe d'apprentissage était ASP.net, pas le langage et les bibliothèques de support. Avec l'arrivée de .net 3.5 (LINQ est fantastique) la vie dans le framework .net avec C# est belle.

Quoi qu'il en soit, je ne veux pas transformer ceci en l'histoire de ma vie, mais je voulais simplement partager une expérience brève de quelqu'un qui est passé par toutes les technologies dont vous avez parlé. J'aimerais également mentionner qu'il est bon pour vous d'essayer différents langages/frameworks. J'ai codé pour l'iPhone pendant un an maintenant, et j'ai vraiment apprécié l'Objective-C. C'est de la programmation, et c'est très bien.

En ce qui concerne MFC/.net, les deux ont leurs avantages et leurs inconvénients, et je n'ai vraiment rien contre MFC, mais en termes de progression, je resterais probablement fidèle à C#/.net, mais s'il vous plaît, s'il vous plaît, s'il vous plaît comprenez comment cela fonctionne. La seule chose sur laquelle je vais prêcher est de comprendre comment fonctionne la mémoire en .net, même si "tout est pris en charge pour vous" ;)

Votre connaissance du C/C++ doit être complètement indépendante du fait que vous utilisiez MFC ou non, c'est toujours un langage critique (particulièrement dans la programmation de jeux vidéos basés sur console), mais pour la programmation d'applications de bureau sur Windows, il est de plus en plus difficile de contester le .net. C'est rapide, facile, a un excellent support d'outils, d'excellentes bibliothèques tierces, une énorme communauté croissante, est maintenant cross-platform (Mono) et vous permettra de passer entre toutes les technologies Microsoft actuelles/émergentes (ASP.net, WPF, Silverlight, WCF etc).

Pour autant, je configure toujours Visual Studio en tant qu'environnement C++. Certains habitudes ne meurent jamais ;)

Answer 2

MFC et .NET sont presque à l'opposé l'un de l'autre, chacun étant médiocre à sa manière.

Utiliser MFC, c'est un peu comme vivre dans les ruines en décomposition d'un bâtiment excédentaire de la Seconde Guerre mondiale. Il n'y a pas de panneaux pour avertir des zones dangereuses, et il n'est probablement pas immédiatement évident où trouver de l'eau courante, de l'électricité, ou des toilettes qui fonctionnent - même si tout cela est là, si vous savez où les trouver. Comme tout bâtiment en décomposition, il y a plein de trous dans les murs et ainsi de suite, donc vous pouvez partir quand vous voulez, aussi longtemps que vous voulez. De même, il est assez facile de traîner des choses venant de l'extérieur, bien que ce soit principalement à vous de le faire pour les amener.

Utiliser .NET, c'est comme vivre sur le plateau de The Truman Show. Cela correspond à l'idée qu'une personne se fait de ce que devrait être la vraie vie. Dans ses limites, la vie peut sembler utopique. Mais en fin de compte, c'est juste une cellule de prison agréablement aménagée, et rien de ce qu'il présente comme la vie n'est vraiment réel. Toute votre interaction avec le monde extérieur dépend du bon vouloir d'un réalisateur dont les objectifs visent principalement à améliorer ses propres audiences ; votre bien-être n'est pris en compte que dans la mesure où il l'affecte.

Contrairement à la plupart des prisons, .NET a une voie d'évasion clairement indiquée (étiquetée "P/Invoke"). Mais comme toute bonne évasion de prison, c'est un tuyau d'égout long d'un mile. La plupart des résidents en sont conscients, mais presque seuls les adolescents qui veulent prouver leur virilité s'y rendent. Les rares qui l'utilisent vraiment le font uniquement en cas de nécessité. Ceux d'entre nous qui ont trouvé nécessaire de le faire trop souvent ont réalisé qu'il vaut mieux rester dehors et ne pas y retourner.

Édition: Comme certaines personnes veulent des cercles et des flèches et un paragraphe au dos de chacun pour être utilisé comme preuve devant le tribunal : La force et la faiblesse de MFC est que c'est principalement un emballage assez mince autour de l'API. C'est une faiblesse car il y a un certain nombre de lacunes dans sa couverture, et parce qu'il fait relativement peu pour "lisser" les endroits où l'API elle-même ne s'emboîte pas particulièrement bien. Par exemple, si quelque chose est implémenté en utilisant COM, cela se montrera généralement directement dans votre code qui l'utilise. C'est une force, car il est assez facile d'étendre MFC pour gérer les zones qu'il ne prend pas en charge par défaut, ainsi que de simplement le contourner et de travailler directement avec l'API quand vous avez besoin de le faire. Il a également été mis à jour relativement peu souvent, donc tandis qu'il peut actuellement produire des applications ayant une apparence raisonnablement "moderne", cela n'a pas toujours été le cas. Étant donné son historique, il serait difficile de prédire s'il continuera à être le cas.

La force et la faiblesse de .NET est que c'est un "emballage" beaucoup plus épais autour de l'API. Il fait beaucoup plus pour "lisser" les différences dans l'API, donc (par exemple) les parties qui sont mises en œuvre en COM ne semblent/agissent pas de manière notable différente des parties qui sont mises en œuvre en appels de fonction C droits. Depuis l'intérieur de .NET, les différences disparaissent. .NET est (actuellement) la technologie préférée de Microsoft, donc il est mis à jour beaucoup plus régulièrement et fait un bien meilleur travail pour s'assurer que votre interface utilisateur suit les dernières directives. Je suppose qu'il est beaucoup plus probable que MFC pour continuer à le faire pendant un certain temps.

La faiblesse de .NET est qu'il est beaucoup plus difficile de contourner ou d'étendre. Fondamentalement, votre seule voie vers le monde extérieur est via P/Invoke. Même pour de petites excursions, c'est moche et douloureux. Essayer de l'utiliser très souvent ou pour quoi que ce soit approchant une extension majeure est un exercice de masochisme.

Si (quasiment) tout ce que vous écrivez peut s'insérer dans ce que .NET supporte, c'est le choix clair. C'est beaucoup plus propre et plus fluide tant que vous restez dans ses limites.

Si vous écrivez du code qui doit fréquemment sortir des limites prises en charge par le framework, MFC fonctionnera probablement beaucoup mieux pour vous. Avec .NET, le modèle .NET s'applique à l'ensemble de votre programme. Avec MFC, il est relativement facile d'écrire des programmes qui utilisent MFC pour leur interface utilisateur, et de faire les choses comme bon vous semble pour tout ce que MFC ne prend pas en charge.

Answer 3

Je pense qu'il est important de connaître le C++ car ce langage va perdurer longtemps. On ne sait jamais quand la programmation en C++ peut être nécessaire, et sur le marché du travail actuel, avoir plus de langages dans votre arsenal ne peut que renforcer votre CV.

En ce qui concerne MFC, je fais de mon mieux pour m'en éloigner. Cela est considéré comme ancien dans les normes informatiques (approchant les 20 ans, je crois), mais Microsoft continue de voir de la valeur à le soutenir avec de nouvelles versions et des packs de fonctionnalités. De ce point de vue, je doute que MFC disparaisse de sitôt. Mais cela ne signifie pas que je veuille programmer avec. La fluidité et la facilité avec lesquelles on peut programmer en C# surpassent largement MFC/C++ tous les jours de la semaine. Le multithreading, les sockets, la manipulation de chaînes, etc. - toutes ces choses sont simplement plus faciles à faire en C# qu'en C++. De plus, C#/.NET est la principale technologie sur laquelle se concentre Microsoft, et je préfère être à la pointe de cette technologie plutôt que de rester sur le banc d'essai MFC en matière de développement de carrière.

Answer 4

Il ne s'agit pas de l'un contre l'autre. Depuis la version 1.1, Windows Forms prend en charge l'hébergement par des clients natifs tels que IE ou MFC dialog. MFC 8.0 a enveloppé le code d'hébergement nécessaire dans ses classes de support Windows Forms, vous n'avez donc pas besoin d'écrire le vôtre. Choisissez la bonne bibliothèque en fonction des besoins actuels de votre projet.

MFC est plus que ses classes d'enveloppe GDI, cependant. À un moment donné, il était conçu comme le remplacement orienté objet de l'API sous-jacente de Win32, un peu comme .Net aujourd'hui. Cependant, MFC n'a pas empêché l'API Win32 de croître et maintenant je peux dire que les API win32 dépassent ce que MFC peut supporter. Le nombre d'API a augmenté des dizaines de fois au cours de la dernière décennie.

D'autre part, Windows Forms était censé être un remplacement uniquement pour le système GDI de Windows. Ce sont le reste des bibliothèques du Framework .NET qui sont censées remplacer le reste de Win32, comme WPF et XNA pour DirectX et System.Speech pour SAPI. Cependant, je peux voir les API win32 dépasser ce que .Net peut suivre sans ajouter significativement la taille de téléchargement dans quelques années.

Par conséquent, Windows Forms ne peut pas faire tout ce que MFC peut faire, il est conçu pour faciliter le RAD basé sur GDI+ et peut inclure ce que MFC ne peut pas faire. Cependant, le Windows Forms basé sur GDI+ est en perte de vitesse alors que Microsoft se recentre sur WPF, tandis que MFC a été relancé sur demande des consommateurs. Si vous concevez des applications pour l'avenir, vous voudrez peut-être prendre cela en considération.

Answer 5

Quel est le problème que vous cherchez à résoudre? Supposons que vous maîtrisez également à parts égales C++/MFC et C#/.NET. Quel ensemble d'outils vous permettrait de construire et de maintenir mieux? (Mieux est subjectif, mais cela dépend encore de vos objectifs)

À moins que je ne travaille beaucoup avec des API natives qui ne sont pas disponibles dans .NET, je choisirai de loin .NET. Le C++ est un excellent langage et rien ne vous empêche de coder en C++ géré pour utiliser le framework .NET et la gestion de la mémoire.

En comparaison, mon observation est que le framework MFC est plutôt bricolé et malcommode par rapport aux formulaires Windows de .NET.