MFC frei?
-
Leprechaun schrieb:
Btw, meines bescheidenen Halbwissens nach, lässt MS die COM-Geschichte, die es einst so gehyped hat, langsam einschlafen, bzw. nutzt es nur noch für den hausinternen Gebrauch.
Nö, auch die neuesten APIs, wie WinRT, basieren auf COM.
-
Schön zu hören, dass COM noch lebendig ist.
Mit dem Link oben habe ich es auch mit VS 2015 Community geschafft.- Wichtig: VS 2015 als Admin öffnen (Rechtsklick auf das VS Icon im Startmenü: Als Admin ausführen!), damit regserv die DLL in der Registry anmelden kann.
- ATL Projekt anlegen und dort später eine Klasse hinzufügen (ATL, z.B. einfaches Objekt)
Also alles vorhanden in VS Community 2015.
Ich habe dies in meinem Kap. 15 in http://henkessoft.de/C++/MFC/MFC Tutorials.htm auf den neuesten Stand gebracht. Vielleicht hilft das auch anderen.
-
Mechanics schrieb:
Nö, auch die neuesten APIs, wie WinRT, basieren auf COM.
Im Kern ja, aber wohl auf einen überarbeiteten COM-Unterbau.
-
Die MFC sind - seit MSVC++6 - über viele Jahre stabil geblieben, wirklich bewundernswert.
-
Ich wüsste nicht, was an dem COM Kern überarbeitet worden sein soll. Ich hab nur gelesen, dass die jetzt wohl ein anderes Format für Interfacebeschreibungen benutzen, aber das ist für mich nur ein marginaler Nebenaspekt.
Ich weiß nicht, ob ich das so bewundernswert finde, dass die MFC noch genauso schlecht ist wie vor 20 Jahren ^^. Die API ist schon sehr unangenehm.
-
Mechanics schrieb:
[...]
Ich weiß nicht, ob ich das so bewundernswert finde, dass die MFC noch genauso schlecht ist wie vor 20 Jahren ^^. Die API ist schon sehr unangenehm.
Ha ha, sehr witzig...was ist an den "neuen" Technologien so angenehm...wenn ich mir "C# und NET" ansehe, dann weiß ich nicht, was besser sein soll, außer die Gewohnheit.
-
Ich rede eher von vergleichbaren C++ APIs, wie Qt
Wobei Qt jetzt auch nicht unbedingt perfekt ist, aber egal. Allein diese ganzen Klassen, die verstecken sollten, dass der Compiler nicht richtig mit Templates umgehen kann, wie CMapStringToString. Es gibt keinen eingebauten Layout Manager, es gibt lauter hässliche Macros usw. usf. Mindestens um 20 Jahre veraltet.
-
ralros schrieb:
Mechanics schrieb:
[...]
Ich weiß nicht, ob ich das so bewundernswert finde, dass die MFC noch genauso schlecht ist wie vor 20 Jahren ^^. Die API ist schon sehr unangenehm.
Ha ha, sehr witzig...was ist an den "neuen" Technologien so angenehm...wenn ich mir "C# und NET" ansehe, dann weiß ich nicht, was besser sein soll, außer die Gewohnheit.
Mhh, was ist an C# und .Net angenehmer als an der MFC? Alles? Wenn es nach der Gewohnheit gehen würde, müsste ich weiterhin C++ bevorzugen, damit verdiene ich bis zum heutigen Tag mein Geld - doch ich halte C#/.Net für weitgehend besser (zumindest in größeren Businessanwendungen).
1. Ich habe nirgens mit binaries zu tun, die sich auch mal zerschießen (gut, Erfahrung ist schon sehr alt - genauer von MFC 1.5 und 4.0).
2. Ich kann Inhalt und Logik sehr gut voneinander trennen, richtig aufgezogen sogar soweit das ich bis auf die eigentliche Oberflächendefinition den Code zwischen Plattformen (Windows, WP, iOS und Android - teilweise sogar MacOS) austauschbar machen kann.
3. Ich brauche weniger Code für den gleichen Aufwand, sofern ich nicht um andere Ziele zu verwirklichen (z.B. bessere Testbarkeit etc.) zusätzlichen Code bewusst in Kauf nehme.
4. Die Werkzeugunterstützung ist unter C# einfach besser (Refactoring usw.).
5. Sobald .Net 5 aus der Beta ist, kann ich sogar den Servercode unabhängig von Windows halten.
6. Ach, und nicht zu vergessen: wesentlich bessere Layout und Skalierungseigenschaften der Oberfläche.
-
Mechanics schrieb:
Allein diese ganzen Klassen, die verstecken sollten, dass der Compiler nicht richtig mit Templates umgehen kann, wie CMapStringToString.
Muss heißen "konnte".
Das Problem, ist eben Code-Stabilität. Wenn man will, dass jedes Programm sofort wieder in der nächsten "Compiler/VS"-Version läuft, dann gibt es oft genug "keine Erneuerung", sondern "nur Neues".Mechanics schrieb:
Es gibt keinen eingebauten Layout Manager, es gibt lauter hässliche Macros usw. usf. Mindestens um 20 Jahre veraltet.
Hässliche Makros?
Wenn ich mir manche template Definitionen und Lamdas der "neuen Programmierweise" (mit der ich auch arbeite) ansehe, dann Frage ich mich was hässlicher ist?Layout Manager? Was meinst Du? Was willst Du layouten? Die ganze Anwendung. Da gebe ich Dir recht.
Aber who cares? Wir reden hier nur über UI. Und da ist QT auch hässlich wie eben auch .NET.
Wenn man nur einen Dialog hat, schön. Aber wenn man richtige komplexe UIs hat, wie eben VS, oder andere dann tritt jede Bibliothek wie QT und auch die MFC an die zweite Stelle und wird nur zu Teilen größerer Werkzeuge und Konzepte.
-
Hübsch oder hässlich - ich denke, wichtig ist, dass man das, was man anwendet, beherrscht und bei Hürden ausreichend Unterstützung und Vorbilder findet. Da kann man bei der Eleganz einige Abstriche machen. Das MFC-Gerüst kann sich da noch sehen lassen und passt gut zu C/C++.
Funktionalität und Produktivität ist sicher ein anderes Thema.
-
Martin Richter schrieb:
Aber who cares? Wir reden hier nur über UI. Und da ist QT auch hässlich wie eben auch .NET.
Darüber lässt sich gut streiten. Ich habe jedenfalls noch kaum hässlichere UIs gesehen, als die klassischen mit WinAPI und MFC geschriebenen Windows Anwendungen, die teilweise nicht einmal sauber mit der Veränderung von Fensterbreiten klar gekommen sind (Beipielsweise diverse Dialoge im älteren VS wo entweder die Fensterbreite fix war, obwohl man nicht alles erkennen konnte, oder sich dann auf einmal beim Aufziehen Buttons vor den Text gewandert sind). Oder Anwendungen die mit aktiver Skalierung kaum mehr bedienbar sind.
Martin Richter schrieb:
Aber wenn man richtige komplexe UIs hat, wie eben VS, oder andere dann tritt jede Bibliothek wie QT und auch die MFC an die zweite Stelle und wird nur zu Teilen größerer Werkzeuge und Konzepte.
In VS wird schon seit einigen Versionen einiges in .Net geschrieben (speziell die Oberfläche, die mindestens zu Teilen WPF verwendet).
-
Martin Richter schrieb:
Mechanics schrieb:
Allein diese ganzen Klassen, die verstecken sollten, dass der Compiler nicht richtig mit Templates umgehen kann, wie CMapStringToString.
Muss heißen "konnte".
Das Problem, ist eben Code-Stabilität.Das meinte ich ja. Damals konnte der Compiler nicht richtig mit Templates umgehen, aber das sollte jetzt seit mindestens 10-15 Jahren kein Thema mehr sein. Da kann man ruhig auch mal mit der Kompatibilität brechen und die API neu aufbauen. Sonst kannst du mir nicht erzählen, dass diese 25 Jahre alte API schön sein soll.
Was ist der an der VS UI jetzt so besonders komplex? Die übrigens mit WPF und nicht mit MFC geschrieben ist. Das sind lauter unabhängige Dock Fenster, ich find die eher ziemlich straight forward. Ich glaub, die Maya Oberfläche ist schon etwas komplexer als VS, und die ist mit Qt geschrieben. Auch die Anwendung die wir in der Arbeit schreiben, hat eine durchaus komplexe Oberfläche, auch diese ganzen Dockings, falls es das ist, was du an VS so komplex findest, und dann noch einiges mehr an Spielereien, und ist auch mit Qt geschrieben. Und auch die Möglichkeit, dass man jeden "Dialog" (oder eher Widgets, die in verschiedenen Kontexten wiederverwendet werden) ganz einfach so layouten kann, dass es skalierbar ist und sich an verschidene Größen anpasst ist schon sehr wichtig.
-
Ich denke, wichtig ist, dass Hobbyisten wissen, dass Ihnen die MFC kostenlos zur Verfügung stehen. Man hat damit modernes C++ und eine bewährte Windows-Klassenbibliothek ohne weitere Maßnahmen in einem Tool zur Hand, mittels F1 kommt das MSDN online dazu, und in http://www.codeproject.com/?cat=2 gibt es eine Unmenge an Code und Infos. Alles für lau. Das ist doch nicht schlecht.
