.Net oder MFC?

[byto]

sri schrieb:

Schneller und einfacher ist relativ. Wenn man 15 Jahre lang mit C++/MFC programmiert hat, dann ist C#/.NET ein totaler Neuanfang. Die Produktivität dürfte anfangs gegen 0 gehen.

Wenn man 15 Jahre lang nur MFC programmiert und jegliche Innovationen verpennt hat, sollte man in der Tat wohl lieber dabei bleiben.

[sri]

byto schrieb:

Wenn man 15 Jahre lang nur MFC programmiert und jegliche Innovationen verpennt hat, sollte man in der Tat wohl lieber dabei bleiben.

Was ist bei .NET innovativ? Dass die Anwendungen 10x länger brauchen, um zu starten und man sich für eine zeitnahe Anzeige eines Startbildschirms ein natives C++-Programm schreibt, welches anschließend die .NET-Anwendung startet? Oder dass man ohne P/Invoke aufgeschmissen ist? Auf solche "Innovationen" kann ich gut verzichten.

[JustAnotherNoob]

Ich finde deine Gründe gegen .NET nicht wirklich stichhaltig.
Mit MFC habe ich nie programmiert, aber es soll wxWidgets ja nicht unähnlich sein, also eenn es kein (zeitliches?) Problem für dich ist etwas neues zu lernen und sonst nichts gegen .NET spricht würde ich dir auch zu .NET raten(als Alternativen gäbe es Java oder andere C++ Bibliotheken. Für Windows Only finde ich .NET in dieser Hinsicht aber schon ziemlich gut) und auch wenn der Benutzer es selbst installieren sollte, kannst du den .NET Installer immer noch in deinen eigenen einbauen.

Was ist bei .NET innovativ?

In Bezug auf GUI?
schonmal was von WPF gehört?

[anmerker]

Ohne Zweifel .NET. Benutze es seit 2 Jahren und bin vor allem von den WinForms begeisert. Im Gegensatz zu dem MFC/wxWidgets Gefrickel macht das sogar richtig Spaß.
Dass MS voll auf .NET setzt und jeglichen MFC Support eingestellt hat, war für mich zwar kein echter Grund, aber irgendwie wollte ich dann doch nicht auf eine aussterbende Lib setzen.

[autsch22]

sri schrieb:

byto schrieb:

Wenn man 15 Jahre lang nur MFC programmiert und jegliche Innovationen verpennt hat, sollte man in der Tat wohl lieber dabei bleiben.

Was ist bei .NET innovativ? Dass die Anwendungen 10x länger brauchen, um zu starten und man sich für eine zeitnahe Anzeige eines Startbildschirms ein natives C++-Programm schreibt, welches anschließend die .NET-Anwendung startet? Oder dass man ohne P/Invoke aufgeschmissen ist? Auf solche "Innovationen" kann ich gut verzichten.

Selten in einem Posting so viel Bullshit gelesen. Alleine der Quark mit P/Invoke zeigt, dass du keine Ahnung hast.

[sri]

anmerker schrieb:

Dass MS voll auf .NET setzt und jeglichen MFC Support eingestellt hat, war für mich zwar kein echter Grund, aber irgendwie wollte ich dann doch nicht auf eine aussterbende Lib setzen.

Solche Gerüchte gewinnen auch durch ständige Wiederholungen nichts an Wahrheit. Mit dem SP1 für VS2008 gab es eine große Oberflächenbibliothek, u.a. auch zur Ribbon-Erstellung. Für VS2010 sind folgende Erweiterungen geplant:

The next release of MFC will provide encapsulations around a number of new Windows platform features. With this functionality you can easily build applications that integrate into features such as desktop search, application restart and recovery functionality, leverage the new Windows UI metaphors such as Live Icons and Rich Preview. These features represent one of the most significant updates to MFC in years.

Mehr: http://channel9.msdn.com/pdc2008/PC26/

Von Einstellung des Supports und einer austerbenden Lib kann ich da nichts herauslesen.

autsch22 schrieb:

Selten in einem Posting so viel Bullshit gelesen. Alleine der Quark mit P/Invoke zeigt, dass du keine Ahnung hast.

Nun, die Sache mit dem Startbildschirm ist keine Erfindung. Das wird bei einer mir bekannten größeren Anwendung wirklich so gemacht. Und jeder zweite C#-Artikel, den ich auf CodeProject lese, kommt nicht ohne P/Invoke aus. Dann kann ich auch gleich nativen Code schreiben.

Aktive Programmiererfahrung mit .NET habe ich wirklich keine. Aber das, was ich bisher gesehen habe, kann mich nicht überzeugen, eine größere funktionierende C++/MFC-Codebasis einfach so wegzuwerfen und quasi wieder bei Null anzufangen. Das ist für mich keine Innovation, das wäre Selbstmord.

[JustAnotherNoob]

Von Einstellung des Supports und einer austerbenden Lib kann ich da nichts herauslesen.

Alleine, dass Microsoft (afaik) ursprünglich vor hatte die WinAPI und MFC komplett durch .NET zu ersetzen zeigt doch, dass es das loswerden möchte. Dass dies so bald nicht geschieht liegt an der Benutzung der beiden und an den Projekten die damit noch gewartet werden und an was weiß ich alles, aber nicht daran, dass Microsoft die MFC am leben erhalten möchte, weil sie gut sei.

r das, was ich bisher gesehen habe, kann mich nicht überzeugen, eine größere funktionierende C++/MFC-Codebasis einfach so wegzuwerfen und quasi wieder bei Null anzufangen

Und sowas ist vermutlich der Grund warum es MFC noch gibt? Da sag ich auch nichts gegen, die Frage ist ob für dieses Projekt eine größere Codebasis vorhanden ist.

Aktive Programmiererfahrung mit .NET habe ich wirklich keine

Ja, das merkt man
P/Invoke hab ich in der Zeit in der ich mit C# programmiert hab(bis es zur Anforderung wurde auch für Linux zu entwickeln) kein einziges mal verwendet, genau so wenig C++/CLI. Die .NET Umgebung hat immer ausgereicht.

[sri]

JustAnotherNoob schrieb:

Alleine, dass Microsoft (afaik) ursprünglich vor hatte die WinAPI und MFC komplett durch .NET zu ersetzen zeigt doch, dass es das loswerden möchte. Dass dies so bald nicht geschieht liegt an der Benutzung der beiden und an den Projekten die damit noch gewartet werden und an was weiß ich alles, aber nicht daran, dass Microsoft die MFC am leben erhalten möchte, weil sie gut sei.

Microsoft hatte es anfangs sicher vor, ist damit aber grandios gescheitert. Es wurde einfach nicht bedacht, dass viele Entwickler (innerhalb und außerhalb von MS) gar nicht gewillt waren, ihre bisherigen Investitionen aufzugeben. Mittlerweile hat MS erkannt, dass C#/.NET nicht die alleinige Zukunft ist.

Ob die MFC gut oder schlecht ist, liegt sicher im Auge des Betrachters. Fakt ist, dass sie eine lange Geschichte hat und immer (mit kleineren Einschränkungen) abwärtskompatibel geblieben ist. Natürlich entspricht sie nicht den Erwartungen, die man heute an eine moderne C++-Bibliothek hat. Dafür müsste man sie wohl von Grund auf wieder neu schreiben. Mir war/ist sie jedenfalls ein großer Helfer und ich möchte sie nicht missen.

JustAnotherNoob schrieb:

P/Invoke hab ich in der Zeit in der ich mit C# programmiert hab(bis es zur Anforderung wurde auch für Linux zu entwickeln) kein einziges mal verwendet, genau so wenig C++/CLI. Die .NET Umgebung hat immer ausgereicht.

Ich habe viel mit der Shell zu tun. Und wenn man mal vom kürzlich veröffentlichten Shell API-Pack absieht, geht es da nicht viel ohne Aufrufe der nativen Funktionen bzw. COM.