rentiert es noch MFC zu lernen?

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

Meist findet man doch das gut, womit man anfängt und die meiste Erfahrung hat.

MFC programiere ich seit der 1.4.x.
Einige der Programme laufen nach mehrfachem Versionswechsel immer noch. Bei uns in der Firma wurden fast alle Client-Anwendungen mit MFC erstellt. Es wurde halt vor Jahren so festgelegt. Das sind inzwischen etliche Projekte, die projektiert und umgesetzt wurden. Versionswechsel machen da schon Arbeit genug. Die stellt man nicht einfach mal auf C# oder sonst was um. Wartungsarbeiten lassen sich gegenüber den Chefs sowieso schlecht begründen.

Trotzdem gibt es natürlich auch C# und Java-Projekte, da wo es Sinn macht. Wenn allerdings mal ganz schnelle Lösungen gefragt sind, nehme ich grundsätzlich erst mal C++ (mit oder ohne MFC).

Für mich macht MFC noch sehr viel Sinn.

Nach meiner Meinung sinkt die Qualität der Entwickler

Das merkt man auch oft an den Fragestellungen einiger "Hobbyentwickler", die mal schnell was zusammenklicken. Da fragt man sich dann echt, ob man noch den richtigen Beruf hat, besonders wenn die Arbeit nicht gewürdigt wird. Das Ergebnis sieht eben oft so einfach aus.

AndyDD

Martin Richter schrieb:

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.

Ja Martin, das ist leider nicht nur bei den Softwareentwicklern so. Programmieren gehört nur zu einem Teil meines Job. Aber selbst Elektroniker oder Mechatroniker haben heute teilweise nicht mal Ahnung von den Grundlagen. Ganz zu scheigen von der selbstständigen Arbeit, also sich mal an ein Problem zu setzen, zu analysieren, Lösungsansätze erarbeiten und schlussendlich auch das Problem lösen.
Aber das wirst Du hier sicher im Forum auch sehen. Es werden oft wieder die gleichen Fragen gestellt, ohne das man vorher mal die Suche bemüht hat. Möglicherweise hab ich das ja in den Anfängen auch so gemacht. Aber es bringt ja nichts dann die komplette Lösung präsentiert zu bekommen, der Lerneffekt ist gleich Null.
Aber nun noch mal zur MFC. Ich arbeite erst seit VS 6.0 damit, bin also was ältere Versionen angeht da nicht so bewandert. Ich geb euch Recht, für schnell mal was zusammenklicken ist das ein ziemlich mächtiges Werkzeug. Wenn dann so eine Frage wie diese auftaucht, dann liest man immer Beiträge, in denen das Ende der MFC probagandiert wird und dann auch wüste Beschimpfungen darauf abgelassen werden. Meist haben die das nicht mal ausprobiert, damit zu arbeiten. Ich schimpfe ja auch nicht auf .NET, hab erst ein bis zwei kleine Tools damit gemacht. Klar muss man sich umgewöhnen und das mit den Pointern und unreferenzierten Variablen verleitet ganz schön schlampigen Code zu schreiben. Sicher ist dieser Zeitaspekt nicht von der Hand zu weisen. Das werdet ihr als reine Softwareentwickler was Software angeht sicher am besten wissen. Das man dann Tools schafft, die einen die Zeit zum Entwickeln verkürzen bzw. unnötige Dinge abnehmen, ist ja dann auch klar.
Es wird eines Tages die Entscheidung von Microsoft sein, ob die das abkündigen oder nicht (wenn eben die Nachfrage danach sinkt). Ich fände es schade wenn das bald der Fall wäre.

thenoname

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

Definitiv. Ich lege sehr viel Wert auf Oberflächen, die sich nicht zu tote animieren. Allerdings ist MFC einen Schritt voraus, was das integrierte Messagesystem angeht und einen Schritt zurück was das modale System angeht. Schade, das man hier aufgehört hat zu entwickeln.

Aber allgemein ist die MFC/SDI ja nicht zum Tote verurteilt. Es werden genügend Updates integriert, die mit einem Manifest zugeladen werden. Der Stil wird ja pro VS Version angepasst. Und das tolle: keine Codeänderung, man muss nicht auf C# umschreiben um die neuen Elemente / Stile zu benutzen.

Mich würde allerdings schon interressieren ob der Support so weitergeht ...
Evtl. fehlt die Zukunftsperspektive ?

Will ich auch mal meinen Senf dazugeben.
Ich bin mit meinen 22 Jahren ja noch junges Gemüse - Dinge wie die ersten MFC-Versionen, wechsel von 16 auf 32 Bit etc... kenne ich ja selber gar nicht.
Man könnte daher meinen, dass ich zu denen gehöre, die dem Hype der neusten Technologien verfallen (hier viel das Stichwort "klicki-bunti" oder so *g*).
War auch anfangs so.
Der Punkt ist: .NET mit C# ist für Anfänger einfach schneller und leichter zu erlernen als es C/C++ ist. Man muss sich nicht mit Dingen unter der Haube wie Pointer, Speicherlecks etc kümmern - man vertraut halt blindlinks auf den Garbage Collector - der wirds schon richten :).
Inzwischen seh ich's differenzierter: Klar - bei .NET kann man sich mehr auf das Problem konzentrieren, und die eigentliche Programmierung fällt etwas mehr in den Hintergrund. Aber eine zur laufzeit Interpretierte Engine ist nun mal langsamer - und der Overhead des Frameworks in Bezug auf Speicherverbrauch ist auch nicht ohne.
Ich habe für mich daher folgende Entscheidung getroffen (privat natürlich - in der Firma liegen diese Entscheidungen ja nicht bei mir ):
Für kleine Tools, die ich mal eben fix brauche, nehme ich .NET - da ist es mir wurscht ob die Applikation ein paar ms langsamer ist oder 1 bis 5 MB mehr Speicher belegt - ich kann mir im Designer fix die Oberfläche zusammen klickern, die nötigen Funktionen und Events implementieren und die Kiste läuft.
Bei größeren Plänen greife ich aber inzwischen zu den MFC - schlisslich soll ja auch bei langsameren und alten Rechnern alles gescheit laufen - und nicht jeder hat das aktuelle .NET Framework installiert.

Also wie schon erwähnt wurde - die Aufgabe bestimmt das Werkzeug

Und die MFC wird es sicherlich noch länger geben, als der Lebenszyklus mittlerer Projekte dauern wird. Klar, MS puscht .NET - sie wären ja auch blöd wenn nicht. Aber mit dem Feature Pack stehen nun auch alle Werkzeuge für mordenes GUI zur verfügung - und das wird sich halten. Office ist ja nun auch mit den MFC entwickelt soweit ich weiß - und ich denke nicht das MS ein Framework einstellen wird, mit dem die eigenen Projekte verwirklicht sind. Und wie schon erwähnt wurde - eine Software mal eben auf ein anderes Framework umzustellen is nicht (das wird bei Microsoft nicht anders sein).

Grüße
Julian