Aktualität, Einsatzgebiete und Zukunft von MFC
lima-city → Forum → Programmiersprachen → C/C++ und D
arbeit
aufgefallen
beispiel
buchen
datenbank
frage
installieren
jahr
leute
mache
machen
paar
programm
programmieren
projekt
sinn
software
studio
suche
windows
-
Hallo Leute,
ich hoffe ich finde hier unter euch jemanden, der sich etwas mit MFC auskennt und etwas mehr Erfahrung im Programmieren hat.
Mir geht es einfach nur darum verschiedene Meinungen und "Prognosen" einzuholen um MFC etwas besser einschätzen zu
können.
Momentan habe ich so ziemlich gegensätzliche Aussagen gehört...
Was ist besonders gut an MFC? Warum sollte man damit Programmieren und nicht mit etwas anderem? Hängt das sehr
stark von der zu programmierenden Anwendung ab? Wenn ja, inwiefern?
Hat MFC noch eine Zukunft? Vor Allem wenn man an DotNet denkt?
Ist MFC erprobter und "sicherer" als DotNet?
Ja ziemlich viele Fragen auf einmal, ich weiß : - ) Vielleicht klären die sich nach und nach... denn ich hab noch mehr Fragen XD
Viele Grüße -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Ich programmiere auf Arbeit seit 2002 mit MFC. Meine Einschätzung ist natürlich sehr persönlich, aber für mich klar:
- Ich hab selten so eine schlechte Klassenbibliothek gesehen,
- Direkt mit WinAPI zu arbeiten geht schneller, einfacher und unkomplizierter als MFC zu nutzen,
- QT ist MFC 100 mal überlegen,
- in den letzten 10 Jahren sind einige große (i.d.R. internationale) Konzerne, von denen wir Software kaufen und entwickeln lassen, von MFC weg zu QT oder Java oder DotNet.
Das ganze hier erstmal als kurzer unbegründeter Abriss. Sobald ich die Muse finde, editier ich das hier noch und füge Begründungen bei.
so long -
Ok, das klingt ja schon fast verheerend. Das heißt, MFC macht es wohl nicht mehr so lange. Zumindest ist es noch bei der
nächsten Visual Studio Version vorhanden, soweit ich weiß.
Brauchen Sie MFC heute also nur noch um "vorhandene" Software zu warten/weiterentwickeln, oder machen Sie auch
neue Projekte? Ist das nicht ein riesen Aufwand Software in anderen Sprachen neuzuschreiben?
Ich habe leider noch sehr wenig Programmiererfahrung. Habe mir vor kurzem ein Buch über Visual C++ und MFC gekauft,
daher würde ich gern wissen "wie schlecht" die Klassenbibliotheken sind. Aber wenn man sogar mit der WinAPI schneller
ans Ziel kommt... das macht mich nachdenklich. Vor allem wenn ich den Vergleich zu DotNet mache. Dort gibt es ja
wirklich schon für fast alles eine Klasse... Aber ist es "nur" der Umstand, den man machen muss, um mit MFC ans Ziel zu
kommen, oder gibt es da noch andere Aspekte? (z.B. Schnelligkeit, Klassen-Dokumentation, Störanfälligkeit)
Von QT habe ich bisher auch nur wenig gehört. Aber scheint mehr als eine Alternative zu sein. Da muss ich mich noch mehr
informieren. Das ist ja mehr als nur eine Bibliothek... das ist ja schon eine ganze Entwicklungsumgebung : - ) -
Zur MFC hab ich hier auch ein Buch herumliegen...und ich schaue da vermutlich nie wieder rein. Allein das Hello WOrld Beispiel geht über mehrere Din A4 Seiten...
Unter C/C++ würde ich jedem empfehlen sich eine Alternative zur MFC zu suchen. Ich schätze mal, die MFC war M$ Versuch C/C++ wie VB Klicki/Bunti freundlich zu gestalten und das zur Zeit von Win95 und wohl auch noch 98.
Das schlimmste was mir bei der MFC aufgefallen ist, dass sie verdammt aufgebläht daherkommt und die Programme mit selbiger es auch sind. -
Das schlimmste was mir bei der MFC aufgefallen ist, dass sie verdammt aufgebläht daherkommt und die Programme mit selbiger es auch sind.
Aber ich glaube z.B. DotNet-Programme sind noch aufgeblähter : - ) Auf jeden Fall kommt man bei C# zum Beispiel zu schnelleren
Erfolgserlebnissen. Auch wenn es da auch ziemlich viel Klickibunit-Zeug gibt, oder vielleicht gerade deswegen... ^^
Also ich hab das Buch "Windows Programmierung mit den MFC" von Frank Budszuhn... So schlecht finde ich es bisher nicht, aber
bin ja auch noch nicht soweit beim lesen : - ) Diese Spaltung von "Dokumenten" und "Grafischer Oberfläche" in MFC ist mir ja
schon schleierhaft, aber vielleicht entdecke ich da noch einen Sinn, wenn ich weiterlese und paar Beispiele mache... -
tangoal schrieb:
Das schlimmste was mir bei der MFC aufgefallen ist, dass sie verdammt aufgebläht daherkommt und die Programme mit selbiger es auch sind.
Aber ich glaube z.B. DotNet-Programme sind noch aufgeblähter : - ) Auf jeden Fall kommt man bei C# zum Beispiel zu schnelleren
Erfolgserlebnissen. Auch wenn es da auch ziemlich viel Klickibunit-Zeug gibt, oder vielleicht gerade deswegen... ^^
Also ich hab das Buch "Windows Programmierung mit den MFC" von Frank Budszuhn... So schlecht finde ich es bisher nicht, aber
bin ja auch noch nicht soweit beim lesen : - ) Diese Spaltung von "Dokumenten" und "Grafischer Oberfläche" in MFC ist mir ja
schon schleierhaft, aber vielleicht entdecke ich da noch einen Sinn, wenn ich weiterlese und paar Beispiele mache...
Falls du einen Sinn hinter der Trennung Document / View findest, sag mir bitte bescheid. Denn ich suche den Sinn dort schon seit 10 Jahren. Klasse Idee: Ich hab ein Document (z.B. meine Gehaltsabrechnung) und kann sie in verschiedenen Views verschieden Darstellen: einmal als Tabelle, einmal als Gedicht und einmal als Gemälde. Tolle Idee, aber ich hab noch keine einzige sinnvolle Anwendung davon in der Praxis gesehen.
Das Riesenproblem bei MSVS mit MFC ist, dass soviel automatisiert angelegt wird, dass man garnicht mehr weiß, was der eigene Code tut. Dann ist auch noch alles in Makros, die unergründlich sind und wenn man z.B. im Nachhinein mit der Hand noch etwas an der Main-Event-Loop drehen will, geht das ganze Projekt unwiderruflich den Bach runter. Solange man alles schön über GUI zusammenklickt und schiebt, dann läuft das Projekt; sobald man anfängt zu programmieren, steht es an 100 Stellen in Flammen. Komplett undurchsichtig. -
Ok, also kurz zusammengefasst: die MFC sind sehr umständlich und nicht einfach handzuhaben. Aber es muss doch
auch irgendeinen Vorteil bzw. etwas positives geben, oder? Klingt schon etwas verzweifelt, ich weiß : - )
Oder macht Microsoft nur Schrott? ; - )
-
Naja, von wann ist die MFC? 1992 glaub ich. Das sind 15 Jahre ohne Weiterentwicklung. Mit QT ist für MFC nicht nur der Zug abgefahren, sondern auch der Bahnsteig abgerissen wordne.
Warum hat wohl das .net-Framework nichts von der MFC übernommen, sondern imitiert in weiten Strecken die JRE? -
Aber anscheinend programmieren Leute noch damit:
census schrieb: Ich programmiere auf Arbeit seit 2002 mit MFC.
Warum eigentlich?
census schrieb: Falls du einen Sinn hinter der Trennung Document / View findest, sag mir bitte bescheid. Denn ich suche den Sinn dort schon seit 10 Jahren. Klasse Idee: Ich hab ein Document (z.B. meine Gehaltsabrechnung) und kann sie in verschiedenen Views verschieden Darstellen: einmal als Tabelle, einmal als Gedicht und einmal als Gemälde. Tolle Idee, aber ich hab noch keine einzige sinnvolle Anwendung davon in der Praxis gesehen.
Diese Document und View Geschichte klingt einbisschen nach dem Konzept von Datenbanken. Da können auch unterschiedliche Sichten verwendet werden, obwohl die Daten nur einmal vorhanden sind. In dieser Hinsicht scheint es schon Sinn zu machen.
Nur kann ich dies noch nicht aus praktischer Sicht bewerten, da ich weder von MFC noch von Datenbanken sehr viel verstehe.
census schrieb: Naja, von wann ist die MFC? 1992 glaub ich. Das sind 15 Jahre ohne Weiterentwicklung. Mit QT ist für MFC nicht nur der Zug abgefahren, sondern auch der Bahnsteig abgerissen wordne.
QT klingt auf jeden Fall sehr vielversprechend. Für Privatnutzer ist es schon komplett frei, und auch für kommerzielle Zwecke wird (bzw. wurde?) eine Version rausgebracht. Das Gute ist, dass man damit nicht mehr so windowsabhängig ist : - ) Hat schon eine faszinierende Geschichte dieses QT...
census schrieb: Warum hat wohl das .net-Framework nichts von der MFC übernommen, sondern imitiert in weiten Strecken die JRE?
Das ist eine gute Frage. Eigentlich beantwortet diese Frage (fast) alle meine Fragen...
Aber sind die MFC schon auf jedem Windows-basierenden Rechner drauf? Also bei dotNet ist es ja klar, da muss man die Frameworks installieren... -
tangoal schrieb:
Aber sind die MFC schon auf jedem Windows-basierenden Rechner drauf? Also bei dotNet ist es ja klar, da muss man die Frameworks installieren...
Die MFC sind kein Runtime Environment wie Dotnet, sondern nur OO-Wrapperklassen für die Windows-API, für ISO-C++ und ein bisschen Schnickschnack. Dein Kompilat ist am Ende einfacher win32-Binary-Code, der die API aufruft. Du musst auf dem Zielclient also nichts installieren. Den Fehler den halt viele machen ist, sie verteilen den Debugbuild, weil im Studio standardmäßig "Debug" die Zielausgabe ist, und dann fehlen natürlich die Debugger-DLLs auf dem Clientrechner. Der Releasebuild aber läuft ohne weiteres.
Mit QT musst du auch nichts auf dem Client extra installieren, wenn du die QT statisch linkst. Das hat auch den Vorteil der Versionskontrolle.
Warum ich auf Arbeit mit MFC schaffe? Das frag ich mich auch. Wenn's nach mir gänge, dann . . . aber dummerweise geht's nicht nach mir. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
