visual-c++ microsoft - Wird MFC immer noch für Neuentwicklungen verwendet(mit beliebigem Materialvolumen)?




foundation classes (7)

Die Veröffentlichung des MFC Feature Pack (vor ein oder zwei Jahren, iirc) war die größte Erweiterung von MFC seit etwa 10 Jahren und gab der MFC-Entwicklung einen ganz neuen Schub. Ich denke, viele Unternehmen haben sich entschieden, ihre Legacy-Anwendungen beizubehalten, sie voranzutreiben und auf ihrer Basis neue Anwendungen zu entwickeln.

Für mich (als jemand, der eine große MFC-Anwendung verwalten muss) ist das größere Problem die abnehmende Entwicklung und Unterstützung von (Microsoft- und Drittanbieter-) Komponenten anstelle von MFC selbst. Zum Beispiel ist die Portierung auf 64bit nicht einfach, wenn viele alte und nicht unterstützte reine 32bit Active-X Komponenten in der Anwendung zusammengebaut werden.

Ich war nie ein großer Fan von MFC, aber das ist nicht wirklich der Punkt. Ich habe gelesen, dass Microsoft eine neue Version von MFC im Jahr 2010 veröffentlichen wird und es hat mich wirklich merkwürdig getroffen - ich dachte, MFC wäre tot (keine böse Absicht, das habe ich wirklich).

Wird MFC für neue Entwicklungen verwendet? Wenn ja, was ist der Vorteil? Ich konnte mir nicht vorstellen, dass es irgendeinen Vorteil gegenüber etwas wie C # (oder sogar nur C ++ mit Win32-APIs) hätte.


MFC wird immer noch für einige neue Entwicklung und eine Menge von Wartungsentwicklung (einschließlich innerhalb von Microsoft) verwendet.

Es kann zwar etwas langsamer sein als die Verwendung der Win32-API direkt, der Leistungsverlust ist jedoch sehr gering - selten so viel wie ein ganzes Prozent. Mit .NET ist der Leistungsverlust wesentlich größer (in meinen Tests selten unter 10%, wobei 20-30% typisch und höher für hohe Berechnungen sind. Ich habe zum Beispiel ein Programm, das Eigenvektor- / Eigenwertberechnung durchführt In meiner ursprünglichen Version, die C ++ und MFC verwendet, läuft auf unserer Standard-Testmaschine in weniger als einer Minute ein Testfall.Einige meiner Kollegen entschieden, dass es cool wäre, sie erneut in C # zu implementieren.Ihre Version dauert fast drei Minuten auf der gleichen Maschine (Quad-Core, 16 Gigabyte RAM, also nein, nicht "Legacy-Hardware"). Ich gebe zu, ich habe ihren Code nicht so genau angeschaut, also vielleicht könnte es verbessert werden, aber sie sind Anständige Programmierer, also eine 3: 1 Verbesserung scheint mir unwahrscheinlich.

Mit MFC ist es auch einfach, das Framework zu umgehen und die Win32-API direkt zu verwenden, wenn Sie möchten. Mit .NET können Sie P / Invoke dafür verwenden, aber es ist ziemlich schmerzhaft im Vergleich.


Ich habe letztes Jahr ein Projekt auf Basis von MFC gemacht. Ich bin mir nicht sicher, warum MFC gewählt wurde, aber es war angemessen für die Erstellung einer virtuellen 3D-Grafik-Benutzeroberfläche - ein Gebäudemanagement-Sicherheitssystem - mit 10 Bildwiederholfrequenz effizient auf Win32-basierten PCs aus der Mitte der 1990er Jahre laufen . Die ausführbare Datei (die nur Kern-Win32-System-DLLs benötigt) ist kleiner als 400 K - mit modernen Tools keine leichte Aufgabe.


Es gibt eine Menge Code mit MFC. Ich sehe diese Fragen die ganze Zeit ist diese immer noch verwendet wird, dass immer noch die Antwort verwendet wird ja. Ich arbeite in einer sehr großen Organisation, die immer noch Hunderte von Leuten beschäftigt, die in cobol schreiben. Wenn es jemals im Unternehmen verwendet wurde, wird es weiter verwendet, bis es keine Hardware mehr gibt, die es unterstützen wird. Dann wird ein Unternehmen jemanden dafür bezahlen, einen Emulator zu schreiben, damit der alte Code noch funktioniert.

Die Marine benutzt immer noch Schiffe mit Computern mit Magnetkernen für Speicher und ich bin mir sicher, dass sie Leute haben, die daran arbeiten. Einmal erstellte Technologie kann niemals unterstützt werden. Es ist ein bisschen der Fall von Deus ex machina, wo große Organisationen nicht ganz sicher sind, was ihr System tut und eine so übermächtige Angst davor haben, das Unternehmen in die Knie zu zwingen, sie haben keine Lust, euch neue faule Technologien auszuprobieren Wir bezahlen IBM für die bestmögliche Unterstützung von OS2).

Auch mfc ist eine vollkommen akzeptable Lösung für die Windows-Entwicklung, da es sich um ein Objektmodell handelt, das die System-API umhüllt, die so ziemlich alles ist, was die meisten Leute aus .net herausholen.

Als Nachtrag und da diese Frage nach einem Kopfgeld steht, ist dies ein Zitat von MS bezüglich mfc in VS 11

In jedem Release müssen wir unsere Investitionen auf die verschiedenen Bereiche des Produkts ausgleichen. Wir glauben jedoch immer noch, dass MFC die umfassendste Bibliothek zum Erstellen nativer Desktop-Anwendungen ist. Wir sind fest entschlossen, MFC auf einem hohen Qualitätsniveau zu unterstützen und zu erhalten. Hier ist eine kurze Liste einiger Probleme, die wir in MFC für Visual Studio 11 behoben haben:

Hier ist der link wenn Sie den vollständigen Beitrag lesen möchten


Es gibt Vorteile, wenn Sie sich von verwaltetem Code fernhalten (vielleicht schreiben Sie eine Treiber-Benutzeroberfläche oder machen COM).

Das und es gibt Tonnen von MFC-Code da draußen. Vielleicht arbeiten Sie für Unternehmen X und müssen eine der zahllosen DLLs verwenden, die sie in den letzten zwölf Jahren geschrieben haben.


Coolness spielt keine Rolle bei der Auswahl der Technologie für ein neues System. Ja, wenn Sie ein Student sind oder spielen möchten, wählen Sie, was Sie wollen.

Aber in der realen Welt hat jede Technologie Vor- und Nachteile. Vor einem Jahr hat eines der Teams ein neues Projekt gestartet, es wurde beschlossen, dass es in MFC gemacht wird. Der Grund ist sehr einfach: Sie müssen Windows API viel für Low-Level-Operationen mit dem Drucker, Internet-Explorer und Gott weiß was noch.

C # war nicht einmal im Spiel, die Entscheidung fiel zwischen MFC und QT, beide hatten die benötigte Funktionalität, beide konnten problemlos die Low-Level-Funktionalität integrieren, der einzige Unterschied war, dass einige Teammitglieder bereits MFC-Erfahrung hatten, also nicht müssen mit Schulungen Zeit und Geld verschwenden.

Nehmen wir an, sie wählen C # und WPF:
-1 Sie müssen den gesamten nativen C ++ - und ASM-Code in eine DLL einbinden (das kann schmerzhaft sein, anstatt dass Sie Wrapper schreiben).
-1 Du brauchst jetzt wahrscheinlich zwei Teams, eins für die ui eins für das Winapi-Zeug. Es ist sehr unwahrscheinlich, dass Sie viele Leute finden, die sowohl C # als auch Winapi schreiben können. Einverstanden, dass man auf jeden Fall jemanden braucht, um die Schnittstelle hübsch zu machen (Programmierer sind normalerweise nervtötend und kosten mehr), aber zumindest mit C ++ nur Code, es gibt keine Wartezeit zwischen zwei Teams, brauche eine Modifikation, kein Problem, das ich nicht verstehe Ich muss nicht auf den Designer warten, er wird es später schön machen.
+1 Sie können den UI-Code in C # und WPF schreiben, sagen wir, die UI-Entwicklung ist schneller, aber die UI ist nur 1/4 des Projekts, also ist der Gesamtgewinn wahrscheinlich sehr gering.
-1 Leistungseinbußen: Für jede kleine Operation, die Sie nicht in C # ausführen können, rufen Sie eine externe DLL auf (dies ist ein kleines Problem, da das Programm auf 8 GB RAM Quad Cores läuft).

Fazit: MFC wird immer noch für Neuentwicklungen verwendet, weil die Anforderungen und die Kosten die Technologie für ein Projekt bestimmen und MFC in manchen Fällen sogar die beste ist.


Es ist zwar möglich, Shell-Erweiterungen in verwaltetem Code zu erstellen, dies ist jedoch keine gute Idee, da Probleme bei der Versionsverwaltung auftreten können, wenn mehrere Erweiterungen unterschiedliche Versionen von .NET Framework verwenden. Der Grund dafür ist, dass Shell-Erweiterungen in Bearbeitung geladen werden und ein Prozess nur eine Version des Frameworks laden kann.

C ++ mit ATL wäre meine bevorzugte Wahl, MFC zweitens. Du könntest es auch in C schreiben, aber das ist nur eine Menge Arbeit. Möglicherweise können Sie auch Delphi (nicht verwaltet) oder einige andere Sprachen verwenden.





visual-c++ mfc frameworks lifecycle