Lohnt es noch die MFC zu lernen?
-
Ich wollte jetzt gerne mit der Programmierung von Windowsanwendungen beginnen, doch da stellt sich mir jetzt die Frage, da ja jetzt das NET rausgekommen ist, ob es noch lohnt die MFC zu lernen.
-
es kommt drauf an, wenn du nicht mit Borland Builder VCL/CLX, .NET, OT oder ähnliches arbeiten willst dann kanns du MFC lernen.
Borland Builder -> Langsamm beim Compilieren,
.NET -> der user braucht das .NET framework auf seinen pc, das ist nicht nur ein Download problemm den viele haben generel was gegen .NET weil es vom MS ist
QT -> soll nicht so tolles c++ sein und unter windows muss man zahlen, soll aber ne gute docu haben
-
Die Grundlagen, die Du dabei lernst, bleiben Dir länger erhalten - Du findest viele Konzepte z.B. in KDE in ähnlicher Form wieder, aber auch in der VCL.
Aber die Frage geht weiter, C++ unter .NET macht nur wenig Sinn, also wenn Du .NET programmierst solltest Du C# lernen. Dann hast Du wiederum aber den Weg auf Windows fester eingeschlagen.
Zur Zeit ist das alles am Scheideweg, letztlich machst Du mit jeder Entscheidung was falsch, aber auch was richtig: denn so weit voneinander entfernt sind die ganze Konzepte ohnehin nicht - auch wenn die Fanatiker dies oft behaupten.
-
@Dimah
QT -> soll nicht so tolles c++ sein und unter windows muss man zahlen
Nein! Es gibt auch eine freie Windows Version von QT, die ist aber veraltet.
Um mal ein paar Vorteile ausfzuzählen
QT -> Platform unabhängig (läuft selbst auf Embeded Systems)!
Borland Builder -> also ich finde, man kann damit ziemlich gut GUIs zusammen klicken, damit kam ich besser klar, als mit MSVC++ (kann auch daran liegen, dass ich damals nicht so gut programmieren konnte), außerdem ist der BCB auch auf anderen Platformen verfügbar.Ich denke aber, dass die meisten GUI+System Wrapper Libs eh ähnlich arbeiten, selbst unter dotNET/Java solltest du keine großen Probleme haben, deswegen ist es nicht so schlimm, wenn du MFC lernst oder nicht, später musst du wahrscheinlich eh umsteigen (egal was du lernst).
(BTW. dotNET ist nicht Platformunabhängig zum GUI+System programmieren geeignet, zwar bietet die MS Implementierung WinForms und spökes an, aber die gehören nicht zum dotNET Standard und sind deswegen nicht/nur eingeschränkt auf anderen Systemen verfügbar!)
-
Ok, dann bleibe ich bei der MFC. Vielen Dank für eure Antworten.
-
Vorher solltest Du auf jeden Fall einen "Schnellkursus" in Win32-API absolvieren, da die MFC diese Schnittstelle nur "umhüllt" (s.u.).
-
Bin eher der Fan von erst MFC und dann WinAPI.
-
Ja eigentlich schon, erst MFC, und wer sich das dann ein bissl low-vevliger anschauen will WinAPI
-
Original erstellt von Marc++us:
Bin eher der Fan von erst MFC und dann WinAPI.echt?
hätte gerade gedacht das du für den umgekehrten Fall bist. 
-
So paar Grundlagen der WinApi kann ich schon.
-
Original erstellt von <prüfen!>:
echt? hätte gerade gedacht das du für den umgekehrten Fall bist. Außgerechnet marc++us als verfechter der OOP sollte für "zuerst WINAPI" sein?
war klar imho .. erst winapi dann mfc ist irgendwie genauso wie erst C dann C++.ps: wenns wen intressiert, ich waer fuer zuerst winapi .. und am besten gar kein mfc .. diese GUI graffelzeugs
.. und dann auch noch plattformabhaengig nene
Ich benutz halt nich gern dinge von denen ich nich weiss was hinter den kulissen ablaeuft. wühl mich lieber von ganz unten nach oben
Danach wär Assembler der perfekte Einstieg imo
[ Dieser Beitrag wurde am 01.02.2003 um 03:47 Uhr von jefff editiert. ]
-
Die Reihenfolge ist Ansichtssache. Wichtig ist, dass man die Zusammenhänge versteht (Eltern-/Kind-Fenster, Nachrichtenverarbeitung, ...), damit man auch einen Blick in den MFC-Sourcecode riskieren kann.