c# para C++ MFC vs.NET?




param c# documentation (8)

MFC et .NET sont à des extrêmes presque opposés, chacun complètement minable à sa manière.

L'utilisation de MFC est à peu près de l'ordre de la vie dans l'épave en décomposition d'un bâtiment excédentaire de la Seconde Guerre mondiale. Il n'y a aucun signe pour avertir sur les zones dangereuses, et il n'est probablement pas immédiatement évident où trouver de l'eau courante, de l'électricité, ou une toilette qui fonctionne - même si tous sont là, si vous savez comment les trouver. Comme n'importe quel bâtiment en décomposition, il y a beaucoup de trous dans les murs et ainsi, vous pouvez partir quand vous le voulez pour aussi longtemps que vous le souhaitez. De même, faire glisser des choses du monde extérieur est assez facile, même si c'est à vous de faire le "glisser" pour l'obtenir.

Utiliser .NET, c'est comme vivre sur le plateau de The Truman Show . Il correspond à l'idée d'une personne de ce que devrait être la vraie vie. Dans ses limites, la vie peut sembler utopique. À la fin, cependant, c'est un peu plus d'une cellule de prison agréablement acceuillie, et aucun de ce qu'il dépeint comme la vie est tout à fait réelle. Toute interaction avec le monde extérieur est soumise au caprice d'un réalisateur dont les objectifs sont surtout d'améliorer ses propres notes; votre bien-être n'est considéré que dans la mesure où cela l'affecte.

Contrairement à la plupart des prisons, .NET a une route d'évacuation bien marquée (appelée "P / Invoke"). Comme la route d'évacuation de toute bonne prison, cependant, c'est un tuyau d'égout d'un mile de long. La plupart des résidents sont conscients de son existence, mais presque les seuls qui y vont sont des adolescents prouvant leur virilité. Les rares qui en font un usage réel ne le font qu'en grande nécessité. Ceux d'entre nous qui l'ont trouvé nécessaire une fois trop souvent ont réalisé qu'il est préférable de rester dehors et de ne pas y retourner.

Edit: Puisque certaines personnes veulent des cercles et des flèches et un paragraphe sur le dos de chacun d'eux pour être utilisé comme preuve au tribunal: la force et la faiblesse de MFC est que c'est surtout une enveloppe assez mince autour de l'API. C'est une faiblesse car il y a un certain nombre de trous dans sa couverture, et parce qu'il fait relativement peu de "lisser" les endroits où l'API elle-même ne s'intègre pas particulièrement bien. Par exemple, si quelque chose est implémenté en utilisant COM, cela apparaîtra habituellement 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 le fait pas par défaut, ainsi que de simplement le contourner et de travailler directement avec l'API lorsque vous avez besoin de le faire. Il a également été mis à jour relativement rarement, alors même s'il peut actuellement produire des applications raisonnablement «modernes», cela n'a pas toujours été le cas. Compte tenu de son histoire, il serait difficile de prédire que cela continuera d'être le cas.

La force et la faiblesse de .NET est que c'est un wrapper 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 implémentées dans COM ne sont pas sensiblement différentes des parties qui sont implémentées comme des appels de fonction C droits. De l'intérieur .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 respecte les dernières directives. Je suppose qu'il est beaucoup plus probable que MFC de 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 à travers P / Invoke. Même pour les petites excursions, c'est moche et douloureux. Essayer de l'utiliser très souvent ou pour tout ce qui s'approche d'une extension majeure est un exercice de masochisme.

Si (presque) tout ce que vous écrivez peut tenir dans ce que supporte .NET, c'est le choix évident. C'est beaucoup plus propre et plus lisse tant que vous restez à l'intérieur de ses limites.

Si vous écrivez du code qui doit assez souvent sortir des limites supportées 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 ils le souhaitent pour tout ce que MFC ne prend pas en charge.

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

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

Y at-il un point à apprendre le MFC? Il se sent un peu démodé, ou ai-je tort? Quels sont les arguments contre et pour .NET par rapport à MFC?

Modifier:

Nous développons des systèmes de traitement 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, peut-être le noyau devrait-il encore être en C ++ natif. Mais l'interface graphique de l'émulateur et toutes les applications environnantes ne sont pas particulièrement critiques.

Et y a-t-il une vraie raison pour laquelle vous devriez remplacer l'application MFC existante?


Je suis passé de C ++ / MFC à C # / WinForms il y a un peu plus d'un an (late bloomer, je sais;)).

Les différences de langue mis à part, il sera beaucoup plus facile de passer de MFC à WinForms que l'inverse. Je pense qu'il est vraiment utile de savoir MFC si vous avez l'intention d'être efficace dans la maintenance des applications existantes. Toutefois:

Aurais-je apprendre le MFC à partir de zéro (compte tenu des technologies existantes)? Non, probablement pas.
Est-ce que j'écrirais de nouvelles applications dans MFC? Non, probablement pas.

Les avantages de MFC sont largement compensés par le support, la flexibilité et la facilité d'utilisation de .NET. Pour ce que c'est, MFC est superbe, et je suis reconnaissant de l'opportunité d'avoir travaillé avec - cela m'a beaucoup appris . En fin de compte, cependant, il est en voie de disparition.


Quel est le problème que vous cherchez à résoudre? Supposons que vous connaissiez à la fois C ++ / MFC et C # / .NET de manière égale. Quel jeu d'outils vous permettrait de construire et de maintenir mieux? (Mieux est subjective, mais encore une fois cela dépend de vos objectifs)

À moins que je ne travaille beaucoup avec des API natives qui ne sont pas disponibles dans .NET, je vais aller de loin avec .NET. C ++ est un langage génial et rien ne vous empêche de coder en C ++ managé afin de conserver le framework .NET et la gestion de la mémoire.

En comparaison, mon observation est que le framework MFC est très complexe et peu maniable par rapport aux formulaires Windows .NET.


Le code non managé ne s'exécute pas forcément plus vite, cela dépend du code écrit et de celui qui écrit le code. J'ai lu des rapports de benchmarks sophistiqués (source, Code Project), et C # a battu C ++ à certains égards, C ++ a gagné dans d'autres. Cela dépend de votre domaine: j'écris des logiciels pour Flight Simulators, nécessitant donc un environnement non géré. Si vous faites une application graphique, C # peut être le meilleur choix. Pour la programmation de douille à levier bas, C ++ peut retourner de meilleurs résultats. Je n'ai remarqué aucune différence de vitesse sérieuse entre C ++ et C # dans les opérations normales, mais je suis un fan de C ++ pour sa portabilité native et C # pour sa facilité.


J'ai beaucoup utilisé MFC et Windows Forms depuis très longtemps. Je viens de l'industrie du jeu vidéo, donc j'ai dû écrire de nombreuses applications de bureau au fil des ans, et avant .net, MFC était extrêmement utile. Avant même que j'écrivais des outils dans Win32 pur.

MFC a définitivement eu ses bizarreries, mais dans l'ensemble, il a rendu 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 en avez pris connaissance, l'écriture de contrôles personnalisés était un jeu d'enfant. Le meilleur de tous, je pourrais juste coder dans le pur C ++, qui s'est juste avéré être ma langue de choix. De plus, j'ai trouvé MFC très efficace et rapide.

Peu à peu, MFC a commencé à prendre en charge la bibliothèque de contrôle externe, en particulier les bibliothèques d'ancrage / barre d'outils, de sorte que mes outils, tels que les visualiseurs de modèles 3D et les éditeurs de niveau, avaient l'air plutôt sympas.

La plupart des applications que j'ai écrites ont créé l'interface utilisateur par programme, donc l'outil de mise en page de dialogue / fenêtre était plus que suffisant pour mes besoins.

MFC 9 est assez sympa aussi, en particulier avec la bibliothèque Ribbon Control / docking que Microsoft a publié dans le Feature Pack. Donc, il y a encore de la vie dans le vieux chien, c'est sûr! :)

Quand .net 1.0 est sorti, j'ai trouvé la transition assez facile, car il supportait le C ++ géré. Ce n'était pas joli, mais a donné une rampe relativement simple au cadre de .net. Mais le point de basculement pour moi est venu quand j'ai commencé à écrire des outils qui nécessitaient plus de Windows Forms Designer, à l'époque de .net 2.0. J'ai décidé de recommencer et d'apprendre le C #, que j'ai aimé - bien que je ne sois jamais habitué à avoir new () sans delete ();). J'ai alors commencé à écrire des commandes d'utilisateur, trouvant l'expérience entière très gentille et directe. Le framework .net était énorme, bien supporté, et en général j'ai trouvé plus facile de faire à peu près tout en C # / .net. De plus, la compilation était rapide, et la possibilité de refactoriser dans Visual Studio était géniale.

La beauté de c # /. Net est que cela ne vous limite pas à écrire du code managé. Vous pouvez toujours utiliser du code non géré, si la performance est un problème par exemple, ou si vous avez besoin de partager du code entre plates-formes. Par exemple, mes bibliothèques de maths sont écrites en C / C ++, que je mets dans une bibliothèque permettant à C # d'envelopper / d'utiliser le même code, bien que ce soit seulement temporaire. Je vais porter ces bibliothèques à C # à temps pour que tout soit pur.

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

Quoi qu'il en soit, je ne veux pas transformer cela en histoire de ma vie, mais je voulais juste donner une brève expérience de quelqu'un qui a passé en revue toute la technologie dont vous avez parlé. Je voudrais aussi mentionner que c'est bon pour vous d'essayer différents langages / frameworks. J'ai codé pour l'iPhone depuis un an maintenant, et j'ai vraiment aimé Objective-C. Tout est programmation, et tout va bien.

En ce qui concerne MFC / .net, les deux ont leurs avantages et inconvénients, et je ne me soucie pas du tout de MFC, mais pour ce qui est de l'avenir, je m'en tiendrai probablement à C # /. Net, mais s'il vous plaît, s'il vous plaît. comprendre comment cela fonctionne. La seule chose que je vais dire est de comprendre comment fonctionne la mémoire dans .net, même si «tout est pris en charge pour vous»;)

Votre connaissance de C / C ++ devrait être complètement indépendante de savoir si vous utilisez MFC ou pas, c'est toujours un langage critique (particulièrement dans la programmation de jeux vidéo sur console), mais pour la programmation d'applications de bureau sous Windows, il devient de plus en plus difficile .net. C'est rapide, facile, a un excellent support d'outils, d'excellentes bibliothèques tierces, une communauté grandissante, est maintenant multi plate-forme (Mono) et vous permettra de passer de toutes les technologies Microsoft actuelles / émergentes (ASP.net, WPF, Silverlight, WCF etc).

Pour tout cela, cependant, je configure toujours Visual Studio en tant qu'environnement C ++. Certaines habitudes ne meurent jamais;)


Ce n'est pas l'un contre l'autre. Depuis la version 1.1, Windows Forms prend en charge l'hébergement par des clients natifs tels que la boîte de dialogue IE ou MFC. MFC 8.0 a enveloppé le code d'hébergement nécessaire dans ses classes de support Windows Forms afin que vous n'ayez pas besoin d'écrire les vôtres. Choisissez la bonne bibliothèque en fonction des exigences de votre projet actuel.

MFC est plus que ses classes wrapper GDI, cependant. À un moment donné, il a été conçu comme remplacement de l'API Win32 sous-jacente, à peu près 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 se développent à partir de ce que MFC peut supporter. Le nombre d'API a augmenté des dizaines de fois au cours de la dernière décennie.

Windows Forms, d'autre part, était destiné à remplacer uniquement le système GDI de Windows. C'est le reste des bibliothèques .NET Framework qui sont destinées à remplacer le reste de Win32, comme WPF et XNA pour DirectX et System.Speech pour SAPI. Cependant, je peux voir que les API win32 se développent à partir de ce que .Net peut suivre sans ajouter de taille de téléchargement significative 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 la RAD basée sur GDI + et peut inclure ce que MFC ne peut pas faire. Cependant, le Windows Forms basé sur GDI + est en train de se détériorer alors que Microsoft se recentre sur WPF, tandis que MFC est relancé en fonction des demandes des consommateurs. Si vous concevez pour des applications futures, vous pouvez en tenir compte.


Je pense qu'il est utile de connaître le C ++, car le langage va durer longtemps. Vous ne savez jamais quand la programmation en C ++ peut être nécessaire, et dans le marché du travail d'aujourd'hui, avoir plus de langues sous votre ceinture ne fait qu'améliorer votre CV.

En ce qui concerne MFC , je fais de mon mieux pour m'en éloigner. Il est vieux par les normes de calcul (approchant 20 ans, je pense), mais Microsoft voit toujours la valeur de le soutenir avec de nouvelles versions et des packs de fonctionnalités. De ce point de vue, je doute que MFC s'en aille bientôt. Mais cela ne veut pas dire que je veux programmer avec. La fluidité et la facilité avec laquelle on peut programmer en C # battu le pantalon MFC / C ++ tous les jours de la semaine. Threading, sockets, manipulation de chaînes, etc. - tout cela est simplement plus facile à faire en C # qu'en C ++. De plus, C # / .NET est l'objectif technologique principal de Microsoft, et je préfère être à la fine pointe de la technologie que le MFC backburner en matière de développement de carrière.


.NET utilise du code managé. MFC utilise du code non géré. J'ai lu que le code non géré s'exécute plus vite que le code managé. Donc, si vous développez du code en temps réel, vous pouvez utiliser du code non géré.





visual-c++