Mir bringt das Programmieren mit MFC kein Spaß. Da hat ja nicht mehr viel mit Programmieren zu tun. Hab da nen Dialog-Fenster Editor und bastel mir das alles in einer GUI zusammen.

Frage:
Ist ein MFC ein Muss?! Oder komme ich ohne nach ner Zeit nicht mehr weiter?! (Auch beruflich gesehen? Ich weiß so ne Frage wird ungern beantwortet...brauche aber nur paar Meinungen)

Ich mein .css ist auch kein Muss aber irgendwie auch schon. Ich mein wäre sonst ja nicht mehr ganz zeitgemäß.
Wisst ihr wie ich meine Frage meine?

Frage:
Ist ein MFC ein Muss?!

Nein, definitiv nicht. Sowohl privat als auch beruflich kann man gut drauf verzichten und mit anderen Frameworks arbeiten.

Entweder du gehst eine Stufe zurück zur WinApi oder du gehst gleich auf .NET, was ich eher als zeitgemäß bezeichnen würde

Mir bringt das Programmieren mit MFC kein Spaß. Da hat ja nicht mehr viel mit Programmieren zu tun. Hab da nen Dialog-Fenster Editor und bastel mir das alles in einer GUI zusammen.

Das ist doch Quatsch. Nur, weil du grafisch ein paar Controls zusammenklickst, heißt das nicht, dass du so eine richtige Anwendung hinkriegst. Du musst deine Controls schließlich auch irgendwie mit Leben füllen, mit Funktionen versehen. Und das nennt sich dann sehr wohl programmieren. Wir sollten lieber froh sein, dass uns die IDEs mittlerweile so gut - und teilweise auch grafisch - unterstützen. Ich jedenfalls will nicht wieder zurück zur IDE-losen Zeit mit 80*25-Editoren ohne integrierten Compiler/Linker...

Qt mit Designer und Creator, wenn man mag zB.
Wobei man sich bei Qt sehr schnell komplett davon abhängig macht und ein Austausch eher schwierig ist.

Dafür gewinnt man mehrere neue Plattformen auf denen die Software läuft (wenn man denn nicht gleich wieder einige Specials übernimmt, z.B. WinAPI für Fensterinfo auslesen etc.)
Ansonsten bindet man sich mit MFC o.Ä. an Microsoft, was ich für verwerflicher halte, denn dadurch sind die Programme auch nur auf Windows verwendbar!

Aber ein Framework ist auf jeden Fall kein muss für die Zukunft. Vielleicht hast du einige Vorteile, wenn du sie bereits kennst, aber ein muss ist MFC (und auch generell andere Bibliothken) nicht.

ein muss ist MFC [...] kein muss.

Das mag ich so an dir: du bringst die Dinge auf den Punkt und lässt keine Zweifel an deiner Aussage stehen!

drakon schrieb:

ein muss ist MFC [...] kein muss.

Das mag ich so an dir: du bringst die Dinge auf den Punkt und lässt keine Zweifel an deiner Aussage stehen!

Das passiert eben, wenn man schreibt, dann über eine Klammerbemerkung oder sonst was nachdenkt und dann weiter schreibt. :p

Ich bin für Kunstrasen dagegen!

Ich auch... äh... in beiden Fällen!

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

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)

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.

Grüssli

...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.

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

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.

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.

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

http://de.wikipedia.org/wiki/Microsoft_Foundation_Classes

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:

http://c-plusplus.net/forum/viewforum-var-f-is-58.html

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.