MFC veraltet?

[Unix-Tom]

MFC ist sogar in VS 2008 erweitert worden.
Sie ist nicht schön aber gegenüber WINAPI vorteilhaft da Programme schneller entwickelt werden können.
Gibt sicher bessere und schlechtere aber sie wird derzeit definitiv weiterentwickelt.

.

[Bulli]

Das die MFC von MS noch ernsthaft weiter unterstützt wird, sieht man schon alleine daran, das die Ribbons für die MFC rausgekommen sind. Für .NET ist das glaube ich noch nicht passiert? Und wenn doch, dann erst nach den den MFC-Ribbons.
Wenn MS die MFC loswerden wollen würde, würden sie ganz bestimmt nicht Ribbons dafür rausbringen. So gibts für MFC-Anwender keinen Grund von MFC weg zu gehen.

Wenn es um "veraltet" geht, dann ist damit immer gemeint, das es kein schönes C++ ist.

[Gast]

Hallo

Du musst dir überlegen, was du machen willst. Wenn du dir Sprache und Bibliothek aussuchen kannst, würde ich eher zu c# und winforms, wahrscheinlich aber gleich zu wpf tendieren.

chrische

[MSINS]

MFC ist nach wie vor Microsofts Frontschwein Nr.1 und das wird wohl auch noch sehr lange so bleiben, weil die wenigsten Firmen und Entwickler ihre Produkte in C# bzw. der .Net Plattform entwickeln.

[hustbaer]

MSINS schrieb:

MFC ist nach wie vor Microsofts Frontschwein Nr.1 und das wird wohl auch noch sehr lange so bleiben, weil die wenigsten Firmen und Entwickler ihre Produkte in C# bzw. der .Net Plattform entwickeln.

Hihi. Nö, das siehst du falsch. Viele viele Programme von vielen Firmen werden mit .NET entwickelt.
Blubb.

[Walli]

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.

[nep]

Ich schon, und zwar fast überall bei Firmen die zuvor MFC & Co verwendet haben.

[~fricky]

Bulli schrieb:

Wenn es um "veraltet" geht, dann ist damit immer gemeint, das es kein schönes C++ ist.

das spielt überhaupt keine rolle. hauptsache es funzt. und das tut MFC ja.

[Unix-Tom]

Firmen gibt es viele die auf Net setzen.
Man darf nicht immer nur von Anwendungen ausgehen die vielleicht die Firma selbst braucht.
Ich spreche hier von Unternehmen.
z.B. Moss 2007 und NET.
MS Dynamics 2009
etc.

[asc]

Bulli schrieb:

Das die MFC von MS noch ernsthaft weiter unterstützt wird, sieht man schon alleine daran, das die Ribbons für die MFC rausgekommen sind.

Sie wird aber kaum mehr von MS-Seite gepflegt, und auch die neuen Controls sind weitgehend (wenn nicht gar gänzlich) zugekauft. Ich suche aber jetzt nicht den Hersteller heraus, der diese Controls entwickelt hat. Was tatsächlich neu hinzu kam sind wohl einige Konvertierungsfunktionen (kann aber sein das dies nur im Bereich C++CLI war, bin mir hier nicht ganz sicher).

Bestehende MFC-Programme sollte man imho langfristig portieren (nicht von heute auf morgen, aber vielleicht schon einmal so sauber überarbeiten das eine Portierung leichter möglich ist), bei neuen Projekten, gerade wenn sie langfristig geplant sind, würde ich von der MFC aber abraten.

Bulli schrieb:

Für .NET ist das glaube ich noch nicht passiert? Und wenn doch, dann erst nach den den MFC-Ribbons.

Die Ribbonerweiterung für .Net kam soviel ich weiß vor dem 2008er VS raus, kann mich aber auch irren. Und das sie die MFC überhaupt noch marginal pflegen, so liegt es eher daran das noch einige Firmen an der MFC festhalten. Von MS wird aber schon längere Zeit auf andere Alternativen verwiesen.

Bulli schrieb:

Wenn es um "veraltet" geht, dann ist damit immer gemeint, das es kein schönes C++ ist.

Und das die Unterstützung seitens MS nicht mehr wirklich gut ist. Kleine Präsente hier und da haben nichts mit einer guten Unterstützung gemein.

cu André

[Cpp_Junky]

asc schrieb:

...

Bestehende MFC-Programme sollte man imho langfristig portieren (nicht von heute auf morgen, aber vielleicht schon einmal so sauber überarbeiten das eine Portierung leichter möglich ist), ...

Wie soll denn das funktionieren? Also mal abgesehen von der Variante AllesNeuIn.Net(tm) ?

[Gast]

Hallo

dllimport

chrische

[Roflcopter]

Portieren einer MFC Anwendung ist doch unmöglich, es sei denn man hätte das MVC-Pattern benutzt, aber welcher MFC Entwickler tut das schon? Da wird schon das Doc/View von der MFC benutzt und schon steckt man so tief in der MFC drin, dass es keinen Ausweg mehr gibt.

[Bulli]

asc schrieb:

Bulli schrieb:

Das die MFC von MS noch ernsthaft weiter unterstützt wird, sieht man schon alleine daran, das die Ribbons für die MFC rausgekommen sind.

Sie wird aber kaum mehr von MS-Seite gepflegt, und auch die neuen Controls sind weitgehend (wenn nicht gar gänzlich) zugekauft. Ich suche aber jetzt nicht den Hersteller heraus, der diese Controls entwickelt hat. Was tatsächlich neu hinzu kam sind wohl einige Konvertierungsfunktionen (kann aber sein das dies nur im Bereich C++CLI war, bin mir hier nicht ganz sicher).

Völlig irrelevant ob MS irgendwas zukauft! Die Stdlib ist auch von Dinkumware zugekauft. Und?
MS hatte auch mal darüber nachgedacht ein Refactoring Plug-in für C# einzukaufen. Hem... C# wird somit wohl nicht mehr von MS unterstützt?

Sie haben den MFC-Anwendern die Ribbons nachgeliefert, damit die Leute weiter MFC benutzen können. So sehe ich das!

[Shade Of Mine]

asc schrieb:

[
Bestehende MFC-Programme sollte man imho langfristig portieren

Begruendung?

Eine Portierung kostet sehr sehr viel Geld - warum sollte man das zahlen, welchen Vorteil haette man davon?

[berniebutt]

MFC war und ist nur eine drübergestülpte Programmieroberfläche auf die komplexe WinApi. Irgendwo klemmt so etwas immer - und dann ist es besser gleich die WinApi zu benutzen. Wer mit MFC klarkommt, soll dabei bleiben. Ich mag diese oder andere Programmieroberflächen nicht.

[Shade Of Mine]

berniebutt schrieb:

und dann ist es besser gleich die WinApi zu benutzen

Interessant. Warum?

[Fusel.Factor]

berniebutt schrieb:

MFC war und ist nur eine drübergestülpte Programmieroberfläche auf die komplexe WinApi.

Das ist für mich der Grund MFC zu verwenden.

[asc]

Shade Of Mine schrieb:

asc schrieb:

Bestehende MFC-Programme sollte man imho langfristig portieren

Begruendung?

Eine Portierung kostet sehr sehr viel Geld - warum sollte man das zahlen, welchen Vorteil haette man davon?

Wenn ein Programm noch lange in Einsatz sein soll, sollte man sich von Zeit zu Zeit mal Gedanken über die Entwicklung machen. Es heißt ja nicht das man es zwangsläufig portiert, aber man sollte möglichst viel portierbar halten (Sprich: möglichst saubere Programmierung und Kapselung), um nicht später einmal das nachsehen zu haben. Was ist, wenn eine Plattform doch einmal eingestellt wird, oder nach einer angekündigten Zeit ausläuft (ersteres halte ich weder bei der WinApi noch MFC für realistisch, wohl aber zweites durchaus für denkbar).

Ich habe schon die ein oder andere Bibliothek sterben sehen, und man sollte zumindest vermeiden das langfristige Projekte nicht wenigstens eine gewisse Portierung zulassen. Es ist bereits jetzt eine Tendenz dafür zu sehen das nach und nach .Net über die Windows API hinaus weiterentwickelt wird, und ich glaube kaum das die Experimente wie Singularity & Co gänzlich ohne Hintergrund entstanden sind.

Ich glaube kaum das WinAPI/MFC die nächsten 3 Windowsversionen stirbt, aber länger planen will ich persönlich erst, wenn MS eindeutig wieder von .Net Abstand nimmt, oder man die Funktionalitäten wie z.B. bei der WPF in die WindowsAPI zurückfließen lässt.

cu André

[audacia]

asc schrieb:

Es ist bereits jetzt eine Tendenz dafür zu sehen das nach und nach .Net über die Windows API hinaus weiterentwickelt wird, und ich glaube kaum das die Experimente wie Singularity & Co gänzlich ohne Hintergrund entstanden sind.

Aber du machst dir doch hoffentlich nicht die Hoffnung, daß deine WinForms-Projekte unter einem hypothetisch marktfähigen Singularity 3.1 irgendwie lauffähig sein werden?