MFC veraltet?
-
Bulli schrieb:
Na, ihr arbeitet wohl alle bei Start-up-Firmen, wie?
Gut, 30 Jahre kann ich nicht aufbieten, die Projekte laufen bislang nur im Bereich von 10+ Jahren. Nur laufen diese Projekte auf aktuellen Plattformen, und es haben sich im Laufe der Zeiten immer wieder Inkompatibilitäten mit den jeweils aktuellen OS gezeigt.
Sei es nun das bestimmte API-Aufrufe sich inzwischen geändert haben (weil sich das Rechtesystem geändert hat), sei es das Teile des Frameworks auf 16-Bit Funktionen basiert hatten, oder das auf einmal ein Klick innerhalb eines Controls auf einmal einen nervigen Ton auslöst.
Bulli schrieb:
Es ist total unsinnig alten funktionierenden Code zu portieren!
Entweder hast du eine homogene Umgebung die sich auch kaum ändert, oder aber eure Projekte haben das Glück nicht auf Inkompatibilitäten zu stoßen. Vielleicht wird euer Framework ja noch aktualisiert, wenn dies nicht der Fall ist, und davon kein Code sondern nur binäre Bibliotheken existieren, viel Spaß.
Bulli schrieb:
Um so länger er existiert, um so unwahrscheinlicher wird ein Port!
Gerade wenn der Code nicht von zeit zu Zeit etwas aktualisiert und überarbeitet wird, und ebenso wird mit diesen Bedingungen auch die Wartbarkeit immer aufwendiger.
Bulli schrieb:
Aber ich bezweifel mal, das die meisten MFC-Projekte gestern angefangen wurden...
Das Thema begann auch mit der Frage aktuell damit zu beginnen. Und Code prinzipiell portabel zu halten ist sicher kein Fehler, da es meist auch die Wartbarkeit erhält.
cu André
-
berniebutt schrieb:
Shade Of Mine schrieb:
Interessant. Warum?
Weil ich dann sehe, was passiert und nicht mühsam in den Beschreibungen fremder Klassenbibliotheken herumwühlen muss. Erscheint mir einfacher!
Verstehe ich nicht.
Ob ich jetzt SetEvent(evt) oder evt.SetEvent() mache - wo ist der große Unterschied?MFC ist ja eben so käse gekapselt dass es eigentlich nur eine mehr oder weniger objekt orientierte version der winapi ist.
ich würde die argumentation bei Qt, gtk, etc. verstehen - diese abstrahieren ja wirklich, aber die MFC bietet ja keine abstraktionsschicht. das ist zB mein kritik punkt - es ist einfach nur die winapi 1:1 nur eben statt foo(bar) schreibt man bar.foo() und man hat als bonus grafische editoren für die fenster
-
Shade Of Mine schrieb:
berniebutt schrieb:
Shade Of Mine schrieb:
Interessant. Warum?
Weil ich dann sehe, was passiert und nicht mühsam in den Beschreibungen fremder Klassenbibliotheken herumwühlen muss. Erscheint mir einfacher!
Verstehe ich nicht.
Ob ich jetzt SetEvent(evt) oder evt.SetEvent() mache - wo ist der große Unterschied?MFC ist ja eben so käse gekapselt dass es eigentlich nur eine mehr oder weniger objekt orientierte version der winapi ist.
ich würde die argumentation bei Qt, gtk, etc. verstehen - diese abstrahieren ja wirklich, aber die MFC bietet ja keine abstraktionsschicht. das ist zB mein kritik punkt - es ist einfach nur die winapi 1:1 nur eben statt foo(bar) schreibt man bar.foo() und man hat als bonus grafische editoren für die fenster
Seit wann hat man einen Editor für Fenster bei der MFC? Da kann ich doch nur Dialoge und ein paar vordefinierte Sachen fürs Hauptfenster einstellen. Wenn man sich dagegen den QT Designer anschaut...
-
Hö??? schrieb:
Seit wann hat man einen Editor für Fenster bei der MFC? Da kann ich doch nur Dialoge und ein paar vordefinierte Sachen fürs Hauptfenster einstellen. Wenn man sich dagegen den QT Designer anschaut...
Dialoge sind auch Fenster
-
Shade Of Mine schrieb:
MFC ist ja eben so käse gekapselt dass es eigentlich nur eine mehr oder weniger objekt orientierte version der winapi ist.
Du hast es aber auch mit dem Käse
Shade Of Mine schrieb:
und man hat als bonus grafische editoren für die fenster
Ressourceneditoren kannst du ebensogut für Plain-WinAPI-Anwendungen benutzen.
Aber nichtsdestotrotz existieren die MFC ja nicht ganz grundlos; es ist nicht so, daß sie nicht zur Codereduktion beitragen könnten. Aber es gibt, wie nun oft genug hervorgehoben wurde, genügend bessere Abstraktionen des Windows-API.
-
^^der im visual studio eingebaute codegenerator für mfc-anwendungen ist aber ganz ok. für kleine dielogbox-basierte quick-and-dirty windows-progrämmchen ist das alles sehr gut zu gebrauchen. nur dieses microsofteigene mvc document/view-zeug ist recht übel, aber sowas muss man ja nicht benutzen.
-
Alles irgendwie klar und doch nicht. Wenn ich Birnen haben will, pflanze ich keinen Apfelbaum. Es kommt also darauf an, was man für Obst haben will! Für mich ist Windows das Obst und was ich genau damit machen will leistert mir die WinApi. Wenn ich morgen etwas anderes haben will, muss ich mich vielleicht neu orientieren. Natürlich macht es wenig Unterschied, ob ich für WinApi Strukturen fülle und Funktionen aufrufe oder ob ich stattdessen Properties festlege und auf Events reagiere. Ich denke aber, MFC und Co. kapseln die komplexe Funktionalität der WinApi zwecks einfacher Handhabung so sehr, dass man irgendwann auf eine nicht berücksichtigte Funktionalität stösst. Und dann fängt die mühsame Sucherei an!
-
berniebutt schrieb:
Alles irgendwie klar und doch nicht. Wenn ich Birnen haben will, pflanze ich keinen Apfelbaum. Es kommt also darauf an, was man für Obst haben will! Für mich ist Windows das Obst und was ich genau damit machen will leistert mir die WinApi. Wenn ich morgen etwas anderes haben will, muss ich mich vielleicht neu orientieren. Natürlich macht es wenig Unterschied, ob ich für WinApi Strukturen fülle und Funktionen aufrufe oder ob ich stattdessen Properties festlege und auf Events reagiere. Ich denke aber, MFC und Co. kapseln die komplexe Funktionalität der WinApi zwecks einfacher Handhabung so sehr, dass man irgendwann auf eine nicht berücksichtigte Funktionalität stösst. Und dann fängt die mühsame Sucherei an!
Bei der MFC stimmt das definitiv nicht, diese zieht eine so dünne Schicht über die Winapi, dass du jederzeit und ohne Probleme Winapi-Funktionen aufrufen kannst.
Selbst in QT hatte ich bisher noch keine Probleme mir das HWND zu holen und Winapi-Funktionen aufzurufen.Und was heißt mühsame Sucherei? Funktionalität die ich einmal im Jahr brauche, die muss ich ja nicht in zwei Minuten finden. Nur weil du täglich mit der Winapi arbeitest kennst du wohl auch nicht alle 4000+ Funktionen auswendig, oder?
Wofür gibt es Foren, Mailinglisten, Usenet und Suchmaschinen, wenn nicht um Wissen zu teilen?
-
Profi-Programmierer schrieb:
Nur weil du täglich mit der Winapi arbeitest kennst du wohl auch nicht alle 4000+ Funktionen auswendig, oder?
Nein natürlich nicht! Meine hier geäusserte Meinung bleibt: "Jeder soll das benutzen, womit er am besten klarkommt!" Ich suche nicht gerne lange, wenn es irgendwann irgendwo mal klemmt.
-
berniebutt schrieb:
Ich denke aber, MFC und Co. kapseln die komplexe Funktionalität der WinApi zwecks einfacher Handhabung so sehr, dass man irgendwann auf eine nicht berücksichtigte Funktionalität stösst.
Nein, das ist falsch.
@audacia:
äh, du kennst schon den unterschied zwischen den MFC Dialog Editoren und einfachen Resourcen Editoren?
Es geht ja nicht nur um das Fenster Layout selber...Und eigentlich finde ich die MFC enorm hässlich. Leider gibt es für C++ keine ordentliche GUI Library die nicht kompletter Käse ist... Deshalb Java/.NET/Webservices für die frontends...
-
Shade Of Mine schrieb:
berniebutt schrieb:
Ich denke aber, MFC und Co. kapseln die komplexe Funktionalität der WinApi zwecks einfacher Handhabung so sehr, dass man irgendwann auf eine nicht berücksichtigte Funktionalität stösst.
Nein, das ist falsch.
"zwecks einfacher Handhabung so sehr" mag falsch sein, aber ansonsten liegt er schon richtig. Nur ist das kein Argument gegen die MFC: daß Abstraktionen lückenhaft sind, ist noch kein Grund, auf Abstraktionen zu verzichten.
Shade Of Mine schrieb:
äh, du kennst schon den unterschied zwischen den MFC Dialog Editoren und einfachen Resourcen Editoren?
Ich glaube, ich habe damals in VC 6 beide benutzt; ich erinnere mich an einen sehr guten Ressourceneditor, aber miserablen GUI-Designer. Vielleicht habe ich die beiden deshalb nicht unterscheiden können
Was ist denn der Unterschied? Daß der MFC-Dialogeditor in der Lage ist, mir automatisch neue Eventhandler zum Code hinzuzufügen, oder übersehe ich etwas?Shade Of Mine schrieb:
Und eigentlich finde ich die MFC enorm hässlich. Leider gibt es für C++ keine ordentliche GUI Library die nicht kompletter Käse ist...
Stimmt. Ich kenne eine gute für C++, aber die wurde in Delphi geschrieben
Tatsächlich begünstigt die Sprache C++ nicht eben schöne UI-Bibliotheken.