rentiert es noch MFC zu lernen?

guenni81

@ChuckNorris
Meines wissens ist auch erst vor kurzem (oder soll demnächst) die neue MFC (Next Generation) rauskommen.
Natürlich sind auch GUI Frameworks wie QT4, wxWidgets, etc. interessant, wenn man seine Programme ebenfalls für andere Betriebssysteme portieren will.

Hallo

Wenn man eh nur Windows macht, sollte man sich aber auch mal .net und wpf reinziehen. Finde ich persönlich deutlich besser zu handhaben als MFC. Ich kenne es aber nur in Kombination mit c#.

chrische

Machine

Von .NET Oberflächen bin ich persönlich nicht so überzeugt.
Für kleinere schnelle Oberflächen, also kleine Tools, ist es auf jeden Fall in Ordnung, auch mit C#... aber wenn man wirklich größere Anwendungen erstellen will, dann finde ich persönlich die MFC besser.
Allerdings kenne ich auch Leute, die für alles auf .NET schwören, das ist also in meinen Augen Geschmackssache...

lass die Finger von der mfc
1. kannst du genausogut mit reiner winapi programmieren
2. wird die mfc nicht mehr benutzt und durch .NET ersetzt

Hallo

Machine schrieb:

Von .NET Oberflächen bin ich persönlich nicht so überzeugt.
Für kleinere schnelle Oberflächen, also kleine Tools, ist es auf jeden Fall in Ordnung, auch mit C#... aber wenn man wirklich größere Anwendungen erstellen will, dann finde ich persönlich die MFC besser.

Warum? Gerade wenn es größer wird dann wird es mit Mfc doch recht schnell unübersichtlich. Das fand ich zumindest.

chrische

Machine

chrische5 schrieb:

Hallo

Machine schrieb:

Von .NET Oberflächen bin ich persönlich nicht so überzeugt.
Für kleinere schnelle Oberflächen, also kleine Tools, ist es auf jeden Fall in Ordnung, auch mit C#... aber wenn man wirklich größere Anwendungen erstellen will, dann finde ich persönlich die MFC besser.

Warum? Gerade wenn es größer wird dann wird es mit Mfc doch recht schnell unübersichtlich. Das fand ich zumindest.

chrische

Wie gesagt, ist Geschmackssache, denke ich. Ich habe bis jetzt noch nicht den Überblick verloren und bin immernoch der Meinung, dass man mit der MFC irgendwie mehr Möglichkeiten hat, da man näher ans System kommt als mit .NET..
Weiterhin gibts einen großen Sicherheitsaspekt. .NET Anwendungen kann man relativ leicht "dekompilieren" und so an den Sourcecode kommen (Stichwort .NET Refector). Das ist bei MFC-Anwendungen wesentlich komplizierter...

Da könntem an jetzt aber auch ewig drüber diskutieren, ohne auf ein wirklich handfestes Ergebnis zu kommen..

Martin Richter

gockel123 schrieb:

lass die Finger von der mfc
1. kannst du genausogut mit reiner winapi programmieren
2. wird die mfc nicht mehr benutzt und durch .NET ersetzt

Unqualifiziertes Gebrabbel...

Hallo

Dekompilieren ist sicher ein wichtiger Punkt.

chrische

ich persönlich finde schon das ganze Konzept von .NET sehr schlecht!
Am besten waren doch noch die guten alten executables die ohne irgendein framework oder sonst was über den prozessor rasen

Cpp_Junky

Diese .Net Gummi-Anwendungen sind mir irgendwie suspekt. Da weiss man nie so genau was da eigentlich gerade passiert. Ich weiss auch nicht genau, wie es nach MFC weitergeht, aber diesem .net trau ich nicht übern Weg

Hallo

Kannst du dir alles genau anschauen, wenn du willst.

chrische

ich hasse es auch das Microsoft auf so einen Müll baut!
Nur damit Java nicht am Markt ist -.-

Martin Richter

Auch VC-10 wird eine komplette MFC beinhalten.
Es gibt nicht den leisesten Hinweis bei Microsoft, dass die MFC ausläuft

PS: Seit der MFC 1.0 arbeite ich mit der MFC, produktiv seit der Version 1.5. Seit dieser Zeit hält sich hartnäckig das Gerücht, dass jede neue MFC Version als die "letzte" gilt...
Ich habe langsam die Nase voll gegen diese Gerüchteküche vorzugehen.

PPS: Man kann in dieser Beziehung kann man MVPs vertrauen.
1. Er gehört nicht zu Microsoft.
2. Haben wir direkten Kontakt zur Produkgruppe und bekommen (unter NDA) manche Geheimnisse und Planungen früher gesagt.

Kein Geheimnis ist: Die MFC wird weiterentwickelt!
Das die Zahl derjenigen zurückgeht, die die MFC nutzen ist jedoch auch kein Geheimnis!

warum geht die zahl zurück?
und wird mfc in 2012 und 2014 noch dabei sein

Martin Richter

svenned schrieb:

warum geht die zahl zurück?
und wird mfc in 2012 und 2014 noch dabei sein

Du meinst die Version?
Die Compiler Versionen bei C haben nicht die Jahreszeilen wie VS als Versionunterscheidung.
VC 7.0 = VS.NET 2002
VC 7.1 = VS.NET 2003
VC 8.0 = VS-2005
VC 9.0 = VS-2008
VC 10.0 = VS-2012????

Aber sicher wird es 2012-2014 noch eine MFC geben. Also ja!

ich meinte warum die Zahl der Entwickler weniger wird...
Und was würdest du als profi schätzen wie lang man die MFC noch benutzt oder wie lang sie noch im Visual Studio ist
und dann wird sie durch das lahme .NET ersetzt oder wie?

die mfc sind cool für quick-and-dirty windowsprogramme, also wenn man sich z.b. auf die schnelle ein fensterbasiertes (dialogbox)-tool zusammenstricken will. geht mit nix flotter als damit.
diese document/view-geschichte ist dagegen einfach nur grauenhaft.

Martin Richter

fricky schrieb:

die mfc sind cool für quick-and-dirty windowsprogramme, also wenn man sich z.b. auf die schnelle ein fensterbasiertes (dialogbox)-tool zusammenstricken will. geht mit nix flotter als damit.
diese document/view-geschichte ist dagegen einfach nur grauenhaft.

Unfug!
Ich liebe das Doc/View Modell und halte es für extrem effektiv. Nur sind viele Entwickler in keiner Weise heute mehr in der Lage die verschiedenen Schichten (Daten=Document, Ansicht=View) korrekt zu trennen.
Und Anfängern ist soetwas natürlich erst recht fremd.
Wie alle Modelle oder Klassen-Bibliotheken hat eben jedes eine Philosophie auf die man sich einlassen muss.

Unsere Kernsoftware besteht aus ca. 20 Modulen mit UI, davon sind 70% mit dem Doc/View Model erstelle, 20% sind Wizards und nur 10% sind Dialog basierend.

Ich halte eine SDI Applikation mit CFormView für weitaus effektiver als eine dialogisierende Anwendung.

Martin Richter

svenned schrieb:

ich meinte warum die Zahl der Entwickler weniger wird...
Und was würdest du als profi schätzen wie lang man die MFC noch benutzt oder wie lang sie noch im Visual Studio ist
und dann wird sie durch das lahme .NET ersetzt oder wie?

Nur mal so eine Sammlung (unvollständig):

Es hängt davon ab was Du machst.
Wir arbeiten immer noch mit der MFC weil wir mit einer irrsinnig breiten gewachsenen C++ Library und Klassen Bibliothek, die auf MFC und ATL aufbaut arbeiten.
Es kann keiner bezahlen das neu zu machen. Aber es gibt Zyklen, in denen es gemacht werden muss.

.NET und WEB hängt stark zusammen, jedenfalls in vielen Projekten, die ich so sehe.
Mehr WEB und weniger monolithische Programme bedeutet automatisch mehr .NET und weniger MFC!

Grundsätzlich ist die Lernkurve in .NET schneller (sagt man jedenfalls). Kann ich nicht sicher sagen, denn was ich immer machen will das geht oft genug in .NET genauso schwer wir in purem C++

C++ ist komplexer als C#. In C# ist es weitaus schwerer Fehler zu machen als in C++!
Ich sage nur Pointer, nicht initialiserte Variablen, harte C casts etc.

C++ ist weitaus flexibler als C# und .NET. Dafür ist aber auch die Auswahl der Komponenten um gewaltiges größer und unübersichtlicher. Wer kannschon alle Bibliotheken heute als Anfängerauseinanderhalten und einordnen wo was hingehört: C++/C Sprache, STL, Standard Bibliothek, TR1, ATL, WTL, MFC und dann kommen noch Technologieren wie Win32 API und COM dazu.

Nach meiner Meinung sinkt die Qualität der Entwickler, Entwickler heute sind bei weitem nicht so lernwillig wie vor einigen Jahren und der Druck und die Geschwindigkeit steigt und fast alle legen Tendenzen an den Tag, die sich auch in diesem Forum äußern: Lieber Fragen als Lesen und Lernen.
D.h. auch oft genug: Ein guter C++ Entwickler ist teurer als ein .NET Entwickler, denn er braucht mehr Wissen.
Also will die Wirtschaft auch .NET, was aber nur scheinbar richtig gerechnet ist:
Mag der C# Entwickler auch schneller sein, heißt dies nicht dass ein erfahrener C++ Entwickler nicht bessere, fehlerfreiere und effektivere Software entwickelt hätte.
Aber wer fragt bei Softwareprojekten heute noch nach Nachhaltigkeit?

Zudem hat das Netz dafür gesorgt, dass irrsinnig viel Schrott geschwallt und verbreitet wird. Und der viele Schrott sorgt auch für Anfänger Frust, besonders bei einer lernintensiven Sprache wie C/C++.

Kurz: C# und .NET sind ein Zeichen der Zeit. Schnell+fix+klicky-bunti ist angesagt und das mit einer niedrigen Fehlerquote. Es sind fast die selben Argumente, die VB immer stark gegen VC gemacht haben...

Alles zusammmen, es kann besser & wirtschaftlicher sein, in C++ zu entwicklen, es kann besser & wirtschaftlicher sein in C# zu entwickeln.

Will ich einen Nagel in die Wand bekommen entscheide ich mich für das richtige Werkzeug für diese Aufgabe.
Und C#/.NET als Werkzeug kann C/C++ als Werkzeug in keiner Weise ersetzen. Aber vieles was früher eben nur mit C/C++ ging geht eben auch alternativ mit C#/.NET!
Wir haben mehr Werkzeuge heute!
Der Entwickler entscheidet.

Aber ich habe bestimmt noch Argumente vergessen und will hiergewisslich keinen Flame War anfangen...

EXDW

also ich hab lange zeit c++ programmiert - hab hier noch irgendwo meinen eigenen WinAPI wrapper rumliegen
dann bauen unsere meisten produkte weiterhin auf MFC - hab kein problem damit
was mein privat zeug angeht programmier ich mitlerweile sehr gern WPF + C#
WPF + C++ - DAS waere mal was ganz feines #gg