Wo sind die Vor- und Nachteile von Visual Component Library (VCL) von Borland gegenüber der MFC von Microsoft?
-
Da ich bei dieser Frage faire Chancen für beide Seiten geben möchte und es nicht zu Überstimmungen kommt, stelle ich diese Frage nicht in den jeweiligen VCL oder MFC Unterforen, sondern hier im allgemeinem Programmierforum.
Diese Frage soll nur die Vor- und Nachteile von VCL und MFC beleuchten.
Andere Toolkits wie z.b. .Net, Qt, GTK+, wxwidgets sind hier nicht gefragt.
Es sollte nur um die beiden obigen gehen.
-
MFC oder VCL schrieb:
Da ich bei dieser Frage faire Chancen für beide Seiten geben möchte und es nicht zu Überstimmungen kommt, stelle ich diese Frage nicht in den jeweiligen VCL oder MFC Unterforen, sondern hier im allgemeinem Programmierforum.
MFC und VCL sind vom Stil her beide recht altbacken, wobei die Compilerunterstützung (VCL unter dem C++ Builder, MFC unter Visual Studio) für die VCL besser ist (schneller zu Ergebnissen führt). Die MFC lässt einen mehr Beeinflussung, dafür ist mehr Handarbeit nötig.
Die VCL krankt wiederum recht stark in der mangelhaften Sprachunterstützung (zumindestens wenn man von C++ spricht, was ich bei einem Vergleich MFC vs. VCL erwarte). Einiges in der VCL funktioniert nicht so, wie es Seitens des C++ Standards eigentlich sein müsste (Konstruktorreihenfolgen, __fastcall, ...).
cu André
P.S: Ich bin weder von der MFC noch der VCL begeistert, wobei mir bislang noch kein UI-Framework unter C++ vollständig gefallen hat.
-
Nun muß ich doch einmischen
Da ich überzeugter VCL-Nutzer bin, ist natürlich meine Objektivität fraglich, auch und insbesondere hinsichtlich der MFC. Jedoch kann und will ich die Vorteile und Alleinstellungsmerkmale der VCL umreißen.
Im Gegensatz zu den MFC ist die VCL ein RAD-Framework, das massiv Gebrauch von Reflection und Persistenz macht. Dadurch werden so schöne Dinge möglich wie der WYSIWYG-Formular-Designer. Auch selbstgeschriebene Komponenten integrieren sich praktisch von selbst in den Designer (wenngleich man für aufwendigere Komponenten natürlich spezielle Property-Editoren entwerfen wollen dürfte).
asc schrieb:
MFC und VCL sind vom Stil her beide recht altbacken
In puncto VCL widerspreche ich entschieden. Der Stil ist keineswegs altbacken. Nur ist es eben kein C++.
Die VCL ist in Delphi geschrieben, und sie ist nur in C++ verwendbar, weil C++Builder Compilererweiterungen für einige wesentliche Delphi-Features bereitstellt, die in C++ nicht existieren: Reflection, "Closures" (hier Methodenzeiger mit Objektbindung), Properties und Metaklassen. Auf diesen Konzepten baut die VCL auf, und keines davon würde ich als "altbacken" charakterisieren, auch wenn sie in C++ sehr unüblich sind. Das Property/Delegate/Reflection-Modell beispielsweise ist ebenso im .NET-Framework vertreten.
Zudem werden VCL-Formulare zur Laufzeit mithilfe der Persistenz-Features aus einer Ressource geladen, die der Designer erstellt hat; das vereinfacht unter anderem die Internationalisierung. Dieses Konzept hat Microsoft erst mit WPF wieder aufgenommen.
Ein Problem der VCL ist, daß die IDE gerade Anfänger dazu verleitet, ihre komplette Business Logic im UI-Code zu implementieren. Wenn man ein wenig Erfahrung und Übersicht besitzt, ist es natürlich kein Problem, in VCL-Anwendungen sauber zwischen UI und Funktionalität zu trennen, aber die IDE befördert es nicht unmittelbar.
Überhaupt stellt sich heute kaum mehr die Frage, ob MFC oder VCL. Eher wird man zwischen VCL, WinForms und WPF abwägen; die wenigsten VS-Benutzer dürften dir noch für neue Projekte die MFC nahelegen.
-
audacia schrieb:
asc schrieb:
MFC und VCL sind vom Stil her beide recht altbacken
In puncto VCL widerspreche ich entschieden. Der Stil ist keineswegs altbacken. Nur ist es eben kein C++.
Okay, in C++ sieht der Stil (Auch wegen der Kompatibilitätszusagen) meiner Meinung nach Altbacken aus.
Ich will die VCL nicht schlecht reden, aber sollte hier Embarcadero/Codegear möglichst noch die Kompatibilität erhöhen, damit es sich in C++ besser einfügt.
Wobei ich bei dem C++ Builder und der VCL ohnehin immer das Problem mit der Zukunftssicherheit habe. Mal wird die eine Schiene präferiert, mal die Andere - Klare Zukunftsaussagen in Bezug auf die Richtung die eingeschlagen wird, vermisse ich (Siehe hierzu auch der C++ BuilderX-Ausrutscher, die Unsicherheit einiger Delphientwickler bei der Strategie klassische VCL vs. .Net usw.).
cu André
-
asc schrieb:
Ich will die VCL nicht schlecht reden, aber sollte hier Embarcadero/Codegear möglichst noch die Kompatibilität erhöhen, damit es sich in C++ besser einfügt.
Denkst du da an RAII-Wrapper für Dinge wie BeginUpdate()/EndUpdate() und dergleichen? Das war für C++Builder 2009 geplant, hat es aber nicht ins finale Release geschafft (ebenso der Class-Explorer und Variadic Templates). Vermutlich kommt das dann in der nächsten Version.
Oder meinst du etwas völlig anderes?asc schrieb:
Klare Zukunftsaussagen in Bezug auf die Richtung die eingeschlagen wird, vermisse ich (Siehe hierzu auch der C++ BuilderX-Ausrutscher, die Unsicherheit einiger Delphientwickler bei der Strategie klassische VCL vs. .Net usw.).
Ja, in dieser Hinsicht war die bisherige Strategie Borlands alles andere als optimal. Auch Kylix und Delphi für .NET wären noch in die Ausrutscher einzureihen. Zu der Zeit, da Microsoft das .NET-Framework als vollständigen Ersatz für Win32 ankündigte, war natürlich naheliegend, das sinkende Schiff möglichst bald zu verlassen. Mittlerweile hat sich nun herausgestellt, daß das Schiff keineswegs daran denkt, unterzugehen
Bis jetzt hat allerdings der neue Eigentümer Embarcadero im Gegensatz zu Borland, das die Tools-Sparte ja schon seit längerem loswerden wollte, keine Kursabweichungen verursacht, sondern sich eindeutig zur Zukunft von Native Code bekannt. Und im übrigen ist festzustellen, daß Delphi und C++Builder alles bisher fast unbeschadet überstanden haben. Besonders, daß C++Builder die zweieinhalbjährige C++BuilderX-Eskapade nicht nur überlebt hat, sondern nach wie vor profitabel ist, spricht doch für die Langlebigkeit des Produkts.
-
audacia schrieb:
asc schrieb:
Ich will die VCL nicht schlecht reden, aber sollte hier Embarcadero/Codegear möglichst noch die Kompatibilität erhöhen, damit es sich in C++ besser einfügt.
Denkst du da an RAII-Wrapper für Dinge wie BeginUpdate()/EndUpdate() und dergleichen?
Sowas wäre z.B. schon ein sinnvoller Schritt.
Zudem (aber das ist nicht teil dieser Diskussion) wäre es gut, wenn der Compiler wieder den C++ Standard besser unterstützt (mit der 2009er Ausgabe geht es ja in die richtige Richtung). Und wenn die Unterstützung der Umgebung (Refactoring...) im C++ Bereich mal besser wird (zumindestens war im 2007 das einzige Refactoring das Angeboten wurde nicht einsatzfähig; Oder hat es schon einer Erfolgreich in ein Projekt mit mehr als z.B. 5 Dateien anwenden können?).
asc schrieb:
Mittlerweile hat sich nun herausgestellt, daß das Schiff keineswegs daran denkt, unterzugehen
Naja, auch Codegear hatte das ein oder andere gesagt das Verunsicherung geschaffen hatte (Wobei ich davon nur am Rande mitbekommen hatte, ich arbeite schließlich erst wieder seit ein paar Monaten mit dem C++ Builder).
asc schrieb:
Und im übrigen ist festzustellen, daß Delphi und C++Builder alles bisher fast unbeschadet überstanden haben. Besonders, daß C++Builder die zweieinhalbjährige C++BuilderX-Eskapade nicht nur überlebt hat, sondern nach wie vor profitabel ist, spricht doch für die Langlebigkeit des Produkts.
Ich kenne nicht den Kundenkreis, habe aber gerade in dieser Phase (C++BuilderX) viele Firmen die vorher unter dem C++ Builder entwickelt haben, abspringen sehen. Ebenso einige Firmen die mit Delphi hantiert haben. Dies ist natürlich nur ein kleiner Ausschnitt des Marktes, aber in dem von mir bemerkten Umfeld ist von den Ursprünglichen Firmen nur noch die geblieben, für die ich nun entwickel.
Und auch der VCL-Komponentenmarkt ist nach meinen bisherigen Beobachtungen langsam am austrocknen. Viele Komponentenhersteller haben um 2003-2005 herum ihr letztes Update gebracht...
Ohne die Komponentenprobleme hätten wir wohl schon die Umstellung auf den 2009er gemacht.Natürlich ist auch dies nur ein kleiner Ausschnitt der Realität. Im Gegensatz davon ist in den - von mir beobachteten Firmen - zwar auch die MFC auf einen absteigenden Ast, aber nicht ganz so extrem wie bei der VCL. Umstiegsrichtung in beiden Fällen ist und war Java und C# (.Net).
cu André
P.S: Ich hoffe für den C++ Builder nur das beste, gerade im RAD-Bereich unter C++ ist er imho "die Referenz", aber meine Erfahrung und meine Befürchtungen gehen in eine andere Richtung. Ich sehe in dieser Firma hier noch realistisch 1-2 Compilersprünge im VCL-Bereich, Vorhersagen darüber hinaus sind aber noch nicht abzusehen, und wohl auch abhängig von E/CG...