Ist MFC ein Muss?
-
Ich bin für Kunstrasen dagegen!
-
Fellhuhn schrieb:
Ich bin für Kunstrasen dagegen!
Ich auch... äh... in beiden Fällen!
-
zwutz schrieb:
Microsoft wollte eigentlich längst von der MFC weg, da du nicht der einzige bist, der damit keinen Spass hat
drakon schrieb:
MFC ist jetzt eh langsam eh auch bei Microsoft weg vom Fenster. Jetzt kommt die Zeit von WPF!
Ich hätte gerne offizielle Quellen, welche dies bestätigen.
Die MFC wird immer noch weiterentwickelt. Wäre ein wenig seltsam, wenn man die MFC einstellen möchte, aber sie immer noch weiterentwickelt.Dass die MFC eingestellt wird, ist doch genauso ein nicht haltbares Gerücht, wie die Behauptung, dass die WinAPI durch .NET ersetzt werden soll. Beides völliger Schwachsinn.
Eine kräftige Modernisierung der MFC würde allerdings nicht schaden, aber das ist leider auch Wunschdenken
Grüssli
-
Dravere schrieb:
zwutz schrieb:
Microsoft wollte eigentlich längst von der MFC weg, da du nicht der einzige bist, der damit keinen Spass hat
drakon schrieb:
MFC ist jetzt eh langsam eh auch bei Microsoft weg vom Fenster. Jetzt kommt die Zeit von WPF!
Ich hätte gerne offizielle Quellen, welche dies bestätigen.
Die MFC wird immer noch weiterentwickelt. Wäre ein wenig seltsam, wenn man die MFC einstellen möchte, aber sie immer noch weiterentwickelt.Naja. Das sie von der GDI für Oberflächen wegkommen wollen ist denke ich so. (Schau nur mal Visual Studio 2010 an). Allerdings gibt es afaik nix natives der WPF, also wird man wohl oder übel vorerst auf MFC sitzen bleiben.
Ich habe keine Quellen, aber für was sollten sie denn WPF entwickeln, wenn nicht mit dem Gedanken, dass iwann kein MFC mehr benutzt werden soll?
(Klar nicht Heute oder Morgen, aber schon in der Zukunft)
-
Dravere schrieb:
Die MFC wird immer noch weiterentwickelt.
Kaum noch. Die neuen Komponenten sind weitgehend zugekauft...
Dravere schrieb:
Wäre ein wenig seltsam, wenn man die MFC einstellen möchte, aber sie immer noch weiterentwickelt.
Sagen wir es mal so: Auch die WinAPI wird noch ergänzt. Aber echte Unterstützung sieht anders aus. Auch wenn ich weder WinForms noch WPF als Alternative unter C++ ansehe (Da andere Sprachen, oder MS-Spezifische Erweiterungen nötig sind).
Dravere schrieb:
Dass die MFC eingestellt wird, ist doch genauso ein nicht haltbares Gerücht, wie die Behauptung, dass die WinAPI durch .NET ersetzt werden soll. Beides völliger Schwachsinn.
Interessant ist nur, das .Net inzwischen in Teilen nicht mehr auf die WinAPI aufsetzt, und die WinAPI auch nicht in diesen Bereichen erweitert wurde.
Dravere schrieb:
Eine kräftige Modernisierung der MFC würde allerdings nicht schaden, aber das ist leider auch Wunschdenken
Das die MFC überhaupt wieder Erweiterung erfahren hat (nachdem lange nichts oder kaum was kam), liegt an der Kritik von Kunden. Und wirklich erweitert haben sie die MFC auch nicht.
-
@drakon & asc,
1. Dass die MFC eingestellt werden soll, wird schon sicher seit einem Jahrzehnt erzählt. Bisher ist noch nie irgendwas in der Richtung von Microsoft aus geschehen. Es gab nicht mal eine Empfehlung, dass man wechseln soll. Mit VS2010 kommt zudem auch eine neue MFC Version raus. Wieso Geld in sowas investieren, wenn man es trotzdem einstellen möchte?
2. Die WinAPI ist die Hauptschnittstelle zu Windows und wird sicher nicht ersetzt. .NET basiert immer noch zu einem grössten Teil auf die WinAPI. Ich weiss echt nicht, was einem an Unterstützung bei der WinAPI fehlen soll. Alle neuen Win7 Features wurden über die WinAPI angeboten, über .Net keine.
3. .Net baut zum Teil nicht mehr auf die WinAPI auf. WPF geht über DirectX und ich glaube, dass der XML Parser inzwischen auch direkt in .Net programmiert ist. Allerdings hat sogar WPF immer noch WinAPI Aufrufe drin. Irgendwie muss man zum Beispiel ein Fenster erstellen. Soweit mir bekannt ist, geht das immer noch über die WinAPI. Und zudem, .NET ist viel grösser und kapselt wahrscheinlich immer noch zu einem grösseren Prozentsatz die WinAPI. Daran wird sich wohl in Zukunft auch nicht viel ändern. Es ist auch gar nicht anders möglich.
4. Sucht mal in diesem Forum die WinAPI und MFC Unterforen durch. Seit Ewigkeiten gibt es diese Gerüchte.Grüssli
-
Dravere schrieb:
...Und zudem, .NET ist viel grösser und kapselt wahrscheinlich immer noch zu einem grösseren Prozentsatz die WinAPI. Daran wird sich wohl in Zukunft auch nicht viel ändern. Es ist auch gar nicht anders möglich.
Es sei den man ändert die OS-Basis. Und auch wenn Singularity nur ein Experiment war, würde es mich nicht wundern, wenn irgendwann doch mal etwas neues kommt.
Dravere schrieb:
4. Sucht mal in diesem Forum die WinAPI und MFC Unterforen durch. Seit Ewigkeiten gibt es diese Gerüchte.
Woran auch MS selbst schuld ist. Tut mir leid, aber wenn an einer Schnittstelle erst nach massiver Kritik der Kunden überhaupt noch kleine Verbesserungen durchgeführt werden, ist dies kein Zeichen von großer Unterstützung. Ja, die WinAPI und MFC werden zwangsweise noch länger leben, aber ich würde kein neues Projekt auf diesen aufbauen, wenn nicht wirklich gute Gründe vorliegen.
Von der "Qualität" der WinAPI und MFC einmal abgesehen.
-
asc schrieb:
Es sei den man ändert die OS-Basis. Und auch wenn Singularity nur ein Experiment war, würde es mich nicht wundern, wenn irgendwann doch mal etwas neues kommt.
Zuerst sollen sie das mal wirklich sinnvoll lauffähig hinbekommen. Die entwickeln ja seit 2003 an dem Ding. Sind zwar inzwischen in der Version 2.0 aber scheint immer noch bei weitem nicht markttauglich zu sein.
Zudem will ich dann sehen, wie sie das überhaupt einführen wollen. Jegliche Anwendung welche in C und C++ geschrieben sind, gehen dann nicht mehr? Toll! Mal schauen, wer diese Milliarden (wahrscheinlich deutlich mehr) aufwenden will, um diese Protierungen durchzuführen.
(Man hat ja bis heute noch nicht einmal alle COBOL Projekte portiert, weil es schlicht zu teuer wäre :))
asc schrieb:
Woran auch MS selbst schuld ist. Tut mir leid, aber wenn an einer Schnittstelle erst nach massiver Kritik der Kunden überhaupt noch kleine Verbesserungen durchgeführt werden, ist dies kein Zeichen von großer Unterstützung.
Darf ich fragen, worauf du hier genau anspielst?
Zudem, Schnittstellen Änderungen sind immer so eine Sache. Erst recht in einem so zentralen Ort wie die WinAPI.asc schrieb:
Ja, die WinAPI und MFC werden zwangsweise noch länger leben, aber ich würde kein neues Projekt auf diesen aufbauen, wenn nicht wirklich gute Gründe vorliegen.
Hmmm, programmier du mal ein Programm auf Windows, welches keine WinAPI verwendet. Das will ich sehen
Grüssli
-
Dravere schrieb:
asc schrieb:
Es sei den man ändert die OS-Basis. Und auch wenn Singularity nur ein Experiment war, würde es mich nicht wundern, wenn irgendwann doch mal etwas neues kommt.
Zuerst sollen sie das mal wirklich sinnvoll lauffähig hinbekommen. Die entwickeln ja seit 2003 an dem Ding. Sind zwar inzwischen in der Version 2.0 aber scheint immer noch bei weitem nicht markttauglich zu sein.
Es ging nie um Markttauglichkeit, sondern um Experimente. Davon abgesehen, glaube ich schon das man heutzutage durchaus einen harten Bruch durchführen könnte - sofern man Unternehmen genügend Vorlaufzeit gibt. Es muss ja nicht zwangsweise anfangs ein Mainstream-OS werden (Es gibt genügend Nischen wie man ja auch an google-OS und Co sieht).
Dravere schrieb:
Zudem will ich dann sehen, wie sie das überhaupt einführen wollen. Jegliche Anwendung welche in C und C++ geschrieben sind, gehen dann nicht mehr? Toll! Mal schauen, wer diese Milliarden (wahrscheinlich deutlich mehr) aufwenden will, um diese Protierungen durchzuführen.
Mir ist die Problematik durchaus klar, aber es sollte einmal im Jahrzehnt auch ein Bruch (und sei es ein Kleiner) möglich sein.
Dravere schrieb:
(Man hat ja bis heute noch nicht einmal alle COBOL Projekte portiert, weil es schlicht zu teuer wäre :))
Wobei ich glaube in dem Umfeld auch nicht Windows das OS der Wahl ist...
Dravere schrieb:
asc schrieb:
Woran auch MS selbst schuld ist. Tut mir leid, aber wenn an einer Schnittstelle erst nach massiver Kritik der Kunden überhaupt noch kleine Verbesserungen durchgeführt werden, ist dies kein Zeichen von großer Unterstützung.
Darf ich fragen, worauf du hier genau anspielst?
MFC (schau dir mal an, was die MFC zwischen VS 6.0 und 2005 spendiert bekommen hat - genau, fast garnichts). Wir hatten da in Mitten von ein paar Servicecalls ein bischen was von einem MS-Futzi mitbekommen gehabt... Dazu waren auch einige Nachrichten im Netz zu finden, von wegen das einige Firmen die auf MFC basis Produkte entwickeln, MS einiges an Feuer unterm Hintern gemacht haben.
Dravere schrieb:
Zudem, Schnittstellen Änderungen sind immer so eine Sache. Erst recht in einem so zentralen Ort wie die WinAPI.
Schnittstellenänderungen umfasst für mich auch Ergänzungen.
Dravere schrieb:
asc schrieb:
Ja, die WinAPI und MFC werden zwangsweise noch länger leben, aber ich würde kein neues Projekt auf diesen aufbauen, wenn nicht wirklich gute Gründe vorliegen.
Hmmm, programmier du mal ein Programm auf Windows, welches keine WinAPI verwendet. Das will ich sehen
Indirekt wirst du mit jedem Programm die WinAPI verwenden, direkt ist eine andere Sache.
-
asc schrieb:
Es ging nie um Markttauglichkeit, sondern um Experimente. Davon abgesehen, glaube ich schon das man heutzutage durchaus einen harten Bruch durchführen könnte - sofern man Unternehmen genügend Vorlaufzeit gibt. Es muss ja nicht zwangsweise anfangs ein Mainstream-OS werden (Es gibt genügend Nischen wie man ja auch an google-OS und Co sieht).
Ich glaube nicht, daß Microsoft auch nur im Geringsten daran interessiert ist, seinen 90%-Marktanteil irgendwie durch die Einführung neuer, inkompatibler Plattformen zu verwässern.
-
Hi
Ich hätte mal ne Frage:
Worin liegt der Unterschied zwischen MFC und .NET?
Kann man .NET auch mit C++ nutzen?Wäre nett wenn mir das mal jemand erklären könnte
MfG cobra11freak
-
-
cobra11freak schrieb:
Kann man .NET auch mit C++ nutzen?
Ja, nennt sich dann C++/CLI. Wir haben hier ein eigenes Unterforum für diese Sprache, falls du mal reinschnuppern willst:
-
cobra11freak schrieb:
Worin liegt der Unterschied zwischen MFC und .NET?
1. In der Qualität der Bibliothek. MFC gilt z.B. als recht veraltete OO-Bibliothek.
2. .Net ist für managed Code ausgelegt, MFC für Nativen. Ersteres wird mehr oder weniger beim Starten jedesmal neu übersetzt, letzteres liegt nach der Compilierung bereits im Maschinencode vor.
3. Das .Net Framework ist umfangreicher (auch in der Größe), was wenn noch nicht die nötige Version auf einem Rechner vorliegt, einen gewissen Installationsaufwand bedeutet. Zudem ist .Net neuer und unterstützt weniger Windowsplattformen (je nach Version).cobra11freak schrieb:
Kann man .NET auch mit C++ nutzen?
Jein. Nicht ohne spezifische Spracherweiterungen, oder ohne auf C++/CLI zu wechseln (Eine Sprache die weitgehend C++ Kompatibel ist, aber auch um .Net spezifische Sprachbestandteile erweitert ist). C++/CLI ist aber nicht C++.
Zudem unterstützt C++/CLI einige Sprachkonzepte von .Net nicht vollständig, was das Arbeiten beispielsweise mit der WPF (Windows Presentation Foundation, der neuen UI-Bibliothek ab .Net 3.0) massiv erschwert.
Die Sprache hat wiederum den Vorteil das man relativ leicht bestehende Codeteile mit .Net verbinden kann - ich sehe den Vorteil von C++/CLI eben in diesen Bereich, aber das war es schon. Wenn man wirklich .Net "angenehm" programmieren will, würde ich ansonsten zu einer Sprache wie C# oder VB.net raten.
-
Ich muss mal so ganz doof fragen: Welchen Vorteil bringen diese ganzen Microsoft-Produkte gegenüber den Frameworks, wie Qt oder wxWidgets?
Auf 3 Seiten wird hier über WinAPI, MFC, C++/CLI oder WPF diskutiert.
Die Anwendungen laufen aber doch nur auf Windows und ggf. muss sogar noch .NET installiert werden? Klar, bei Qt muss man größere .dll-Dateien mitliefern.Aber was bewegt einen dazu, z.B. WPF statt Qt zu nehmen?
-
Im Endeffekt ist doch meist nur entscheidend was bei dem Projekt bisher genutzt wurde, da kaum ein Chef einem erlauben wird seine Arbeitszeit damit zu verschwenden andere Toolkits zu nutzen als bisher (bzw alles umzumuddeln).
EDIT: Selbst der Umstieg von Qt3 zu Qt4 ist hier schon ein Riesenthema. Von den ganzen Motif-Altlasten ganz zu schweigen...
-
Amgon schrieb:
Ich muss mal so ganz doof fragen: Welchen Vorteil bringen diese ganzen Microsoft-Produkte gegenüber den Frameworks, wie Qt oder wxWidgets?
1. Die Integration in die Windowsumgebung klappt in der Regel besser.
2. Der Komponentenmarkt ist im Bereich .Net oder ActiveX recht groß.
3. Zumindest bezogen auf .Net (wenn auch mit C#) finde ich es gelungener als Qt oder wxWidgets.Amgon schrieb:
Auf 3 Seiten wird hier über WinAPI, MFC, C++/CLI oder WPF diskutiert. Die Anwendungen laufen aber doch nur auf Windows und ggf. muss sogar noch .NET installiert werden?
MFC/WinAPI/WPF Programme laufen nur unter Windows, oder in Emulationsumgebungen. .Net wiederum ohne WPF mit WinForms statt dessen, ist durchaus auch auf anderen Plattformen lauffähig (z.B. Linux, MacOS), mittels dem Mono-Framework.
Amgon schrieb:
Aber was bewegt einen dazu, z.B. WPF statt Qt zu nehmen?
Das ist sehr einfach: Wenn der Zielmarkt ohnehin Windows ist, gibt es keine Vorteile von QT gegenüber WPF. WPF erlaubt eine recht strikte Trennung zwischen Design und Programmierung, in WPF lassen sich auch Controls leicht auf spezielle Anwendungsfälle anpassen etc.
WPF erlaubt zudem eine nahezu stufenlose Skalierung der Oberfläche [Da Vektororientiert], was durchaus in dem ein oder anderen Projekt ein guter Grund gewesen wäre (Wir hatten einige Kunden denen unsere Oberfläche selbst auf sehr großen Monitor mit großer Schriftart und kleiner Auflösung zu klein waren. Mittels WPF hätten die notfals einen Button auf Bildschirmgröße vergrößern können ;p).
-
Fellhuhn schrieb:
Im Endeffekt ist doch meist nur entscheidend was bei dem Projekt bisher genutzt wurde, da kaum ein Chef einem erlauben wird seine Arbeitszeit damit zu verschwenden andere Toolkits zu nutzen als bisher (bzw alles umzumuddeln).
Richtig, und außerdem sind einige Argumente für Qt auch nicht für alle gültg. Zum Beispiel geht mir das Argument der Plattformunabhängigkeit ziemlich am Ar... vorbei. Wir entwickeln nur für Windows und liefern komplette Systeme inkl. Rechner. Windows hat den Vorteil, dass sich jeder unserer Kunden so halbwegs damit auskennt. Außerdem gibt es keine Schwierigkeiten mit Treibern für die teils recht exotischen Geräte, die wir mitliefern. Wir werden unsere Software wohl nie für ein anderes OS entwickeln. Das Argument zieht also nicht immer. Und die MFC funktioniert imho ganz gut und ist auch akzeptabel und vollständig dokumentiert. Ich sehe keinen Grund, in absehbarer Zeit (bzw. überhaupt) umzusteigen.
Und da sicher sehr viele Firmen MFC-Code produzieren und pflegen, wird MS wohl kaum die MFC abschaffen oder ersetzen. Es werden lediglich Alternativen geschaffen...
-
Fellhuhn schrieb:
Im Endeffekt ist doch meist nur entscheidend was bei dem Projekt bisher genutzt wurde, da kaum ein Chef einem erlauben wird seine Arbeitszeit damit zu verschwenden andere Toolkits zu nutzen als bisher (bzw alles umzumuddeln).
Was im Endeffekt aber auch dazu führen kann das eine Firma völlig "überrascht" wird, wenn auch einmal eine Umgebung auf einem neuen OS nicht mehr läuft (Ist ja auch absolut nicht abzusehen, wenn der Support der Programmierumgebung und der UI-Bibliothek schon 10 Jahre vorher eingestellt wurde).
Grundsätzlich gibt es mehrere Abwägungen die man zu treffen hat:
a) Vorhandenes Wissen bzw. Einarbeitungsaufwand
b) Zielplattform(en)
c) Wie sieht es mit dem Support aus?
d) Programmiert man alles selber, oder möchte man z.B. auch Komponenten hinzukaufen.
...cu André
-
Zugegeben, die GUIs, die mit WPF erstellt wurden sehen schon großartig aus, kein Vergleich zu MFC oder Qt. Aber ist die Verwendung von WPF in C++ denn so einfach?
Ich habe immer gedacht, das funktioniert nur mit C#.
