MFC veraltet?
-
Realistiker schrieb:
Das ist doch völlig unrealistisch, wenn du jede Bibliothek erst einmal kapselst, da hast du ja arbeit ohne Ende und meist kann man die Bibliothek dann doch nicht so ohne Probleme auswechseln, weil man das Interface zu nahe an der verwendeten Bibliothek entwickelt hat.
1. Geht es nicht zwangsläufig um das kapseln von Bibliotheken, auch wenn ich dies teilweise machen würde (Klar, die UI ist meist ziemlich Frameworkabhängig, und auch DB-Zugriffe, die Logik dazwischen würde ich aber tatsächlich versuchen weitgehend frei von speziellen Bibliotheken zu halten, oder den Code wenigstens sauber strukturieren.
2. Code in dem man (unabhängig vom Framework) saubere Trennungen vornimmt (z.B. n-Tier oder ähnliche Konzepte), lässt sich auch eher portieren (Portierung heißt ja nicht zwangsweise das man von heute auf morgen alles umstellt, sondern das man ggf. mit kleinen Bereichen anfangen kann).
3. Code der regelmäßig gewartet wird (Refactoring ist z.B. ein Thema), ist verständlicher, und lässt sich leichter zumindest bezüglich der Logik übernehmen (von einer besseren Wartung ganz zu schweigen, aber da sind ja gerade Entscheider häufig blind: Wozu Refactoring, das bringt doch keine neue Funktionalität).
Es geht wie gesagt nicht um eine zwangsweise Umstellung, sondern nur das man die Wege offen hält um es durchführen zu können, ohne wirklich alles Neuschreiben zu müssen. Und es geht mir darum, das ich bei neuen Projekten lieber zweimal darüber nachdenken würde ob ein Framework xyz noch gewartet wird oder nicht.
cu André
@Zeus: Danke, schön kurz gefasst
-
Walli schrieb:
Sowas lese ich immer nur ueberall, aber ich habe selbst noch keine Firma gesehen, die das so macht. Selbst bei Neuentwicklungen habe ich nicht gehoert, dass jemand von MFC weg ist und auf .NET gesetzt hat.
Ich kenne einige Firmen die .NET einsetzen, für die verschiedensten Dinge. Du brauchst auch bloss mal gucken wieviele C# Programmierer gesucht werden.
Dass eine Firma von MFC weggeht is wieder eine andere Sache. Das passiert oft nicht, weil die Firmen die schon länger MFC verwenden eben nen Haufen C++ Programmierer haben, die sich mit der MFC bereits auskennen, u.U. viel eigenen Library- bzw. Framework-Code etc. Wenn man nicht neue Leute einstellt (was meist bedeutet: andere dafür entlassen) kann es recht lange dauern bis eine Firma von etwas wegwechselt - egal wie mies/veraltet/umständlich/... es ist.
Wenn du dir aber jüngere Firmen bzw. neue Projekte (mit neuen Teams) ansiehst wirst du vermutlich viel mehr .NET als MFC finden. Mittlerweile hoffentlich fast ausschliesslich C#, früher auch noch viel Visual Basic .NET (*schauder*).
-
hustbaer schrieb:
Dass eine Firma von MFC weggeht is wieder eine andere Sache. Das passiert oft nicht, weil die Firmen die schon länger MFC verwenden eben nen Haufen C++ Programmierer haben...
ich kenne da so'nen laden, absolute ms-fanatiker. früher haben sie nur vc (mit mfc) und vb verwendet. seit ca. 3...4 jahren nehmen sie für neue projekte nur noch .NET (c# und vb). an dem alten zeug basteln sie manchmal weiter, aber es wird nicht nach .NET portiert, das wäre viel zu aufwändig. ach ja: die jungs haben irgendwelche sonderverträge mit ms. ich weiss daher nicht, bis zu welchem grad sie von m$ gezwungen werden, das .NET-zeugs einzusetzen.
-
Na, ihr arbeitet wohl alle bei Start-up-Firmen, wie?
Bei uns haben wir produktiven Code in COBOL, der seit 30 Jahren läuft und weiter entwickelt wird (ja, sogar damit neue Projekte angefangen werden!). Und nein, er wird nicht nach Java oder C# portiert. Wenn jemand mit dieser Idee ankommen würde, würde man ihn wohl in eine Zwangsjacke stecken! Es ist total unsinnig alten funktionierenden Code zu portieren! Um so länger er existiert, um so unwahrscheinlicher wird ein Port!Klar, wenn ich gestern angefangen habe ein Projekt in Sprache X anzufangen, und ich stelle fest, das es mit der neuen Sprache Y besser gehen würde, kann ich noch umschwenken. Aber ich bezweifel mal, das die meisten MFC-Projekte gestern angefangen wurden...
-
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!
-
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.
