rentiert es noch MFC zu lernen?

ich programmiere mit C++ und der winApi.
Mir wird aber mmer empfohlen die mfc nicht mehr zu lernen weil sie veraltet is tnicht mehr weiterentwickelt wird und schlecht ist!
aber ich mache ja cpp und kein c !
was sagt ihr

Machine

also ich finde die mfc sehr gut...

und da gabs auch jetzt ein brandneues featurepack mit office 2007 controls usw.. also das mit dem veraltet halte ich mal für blödsinn.

der einzige nachteil ist halt, dass man das nicht direkt wie QT zum beispiel auf linux portieren kann.. aber ganz ehrlich gesagt: ich pfeif auf linux

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.