MFC -> tod
-
Hallo,
ich stelle mich schon immer die Frage:
wird bald MFC sterben ??, mit der neue Technoelegie von M.... net
hat überhaupt c++ Zukunft ????????
Was denkt Ihr ??
-
Zu C++ ist das noch nicht zu 100% raus, da MS lustigerweise den C++-Standard inzwischen mit dem VC7.1 besser abdeckt als jemals zuvor (und besser als jemand jemals erwartet hätte). Würden sie das tun, wenn sie C++ unter Windows eliminieren wollten?
Aber MFC für Oberflächen ist weitgehend tot. Wenn man umfangreiche Funktionalität in der GUI realisieren muß/will, wäre man verrückt jetzt noch neue Projekte mit der MFC zu beginnen.
-
Was nimmt man denn? Gtkmm, Qt?, WxWindows?
Oder alles zu Fuß also WinAPI wrappen?
-
Gtkmmn, Qt oder WxWindows sind nur unwesentlich weniger oder mehr mühsam als MFC.
Zur Zeit würde ich eine Oberfläche (nachdem Borland auch den Builder in den Ruhestand schicken wird) mit C# und .NET machen, wenn es für Windows sein soll. Da ist ungefähr das drin, was mir beim C++ Builder als störend/fehlend aufgefallen ist. Einfacher geht's wirklich kaum noch, GUIs erhalten dann endlich den technischen Stellenwert, den sie verdienen: keinen. Ist nur noch ein Nebenkriegsschauplatz.
-
Kane schrieb:
Was nimmt man denn? Gtkmm, Qt?, WxWindows?
Oder alles zu Fuß also WinAPI wrappen?Qt da man dann das Software Produkt auch noch auf anderen Plattformen vermarkten kann. -> mehr Geld.
-
Marc++us schrieb:
Einfacher geht's wirklich kaum noch, GUIs erhalten dann endlich den technischen Stellenwert, den sie verdienen: keinen. Ist nur noch ein Nebenkriegsschauplatz.
Nannana. Nicht selten entscheidet gerade die GUI, ob ein Produkt ankommt, oder nicht. Die Zielgruppe, die man erreichen will hat darauf einen entscheidenden Einfluß. Von technischer Seite natürlich richtig. Ausgehend davon, daß man GUI und Funktionalität schön sauber getrennt hat.
-
Hi,
wer weiß im Moment eigentlich noch, in was er Programieren soll?
In C# zu Programmieren ist - meiner Meinung nach - sehr einfach, hat allerdings zur Zeit noch den Nachteil, dass es nur auf Windows funktioniert. Und eine Zukunft hat es auch - unter Longhorn werden große Teile mit .Net compatibel sein- fast das ganze Betriebssystem wird auf .Net basieren. - WinFS, das Dateisystem, Avalon, die "Presentationsenergine", deren bestandteil u.A. Windows.Forms ist, und Indigo, dem Internet und Communikationsenergine. Doch wer weiß, ob MS nicht schon bald eine neue Technologie hat, und alles über den Haufen wirft. Wer weiß, ob nich C# 2.0 mit dem aktuellen C# inkompatibel ist, wie es mit Basic.Net und Basic 6 passiert ist. Das kann gean schnell gehen. In C++ hat man die Sicherheit, dass wenn ein Anbieter oder Compiler ausfällt, wird er durch mehrere ersetzt. Doch welche Alternativen gibt es?- Da währen Qt, Gtk, MFC, ... Doch es wird wohl nicht mehr lange dauern, bis MFC nicht mehr weiterentwickelt wird... Die Zukunft ist ungewiss...
-
TheBigW schrieb:
Nicht selten entscheidet gerade die GUI, ob ein Produkt ankommt, oder nicht.
Stimmt zwar, aber trotzdem hat eine GUI technisch gesehen kaum einen Wert.
Es ist viel besser wenn nicht die Programmierer sich das Design ueberlegen und damit rumspielen, sondern einfach die Funktionalitaet implementieren - die GUI kann man ohne Probleme spaeter neu machen.
-
TheBigW schrieb:
Marc++us schrieb:
Einfacher geht's wirklich kaum noch, GUIs erhalten dann endlich den technischen Stellenwert, den sie verdienen: keinen. Ist nur noch ein Nebenkriegsschauplatz.
Nannana. Nicht selten entscheidet gerade die GUI, ob ein Produkt ankommt, oder nicht. Die Zielgruppe, die man erreichen will hat darauf einen entscheidenden Einfluß. Von technischer Seite natürlich richtig. Ausgehend davon, daß man GUI und Funktionalität schön sauber getrennt hat.
Du mußt trennen:
-
Der Kunde zahlt letztlich, weil er die GUI sieht
-
Du verballerst die Entwicklungskosten besser mit der Funktionalität als mit der GUI, denn ohne Funktionalität bemerkt der Kunde, daß die GUI nicht ausreicht und er Mist geliefert bekam
Schlußfolgerung:
Also sollte Dein Augenmerk darauf gerichtet sein, eine möglichst perfekte GUI mit minimalem Aufwand zu erstellen.
Dies ist z.B. mit der MFC oder gar WinAPI nicht erreichbar. Aber die anderen Sachen wie QT & Co sind auch keine löblichen Beispiele.
-
-
Uuups, da bin ich doch auch ein bisschen vom ursprünglichen Thema abgekommen.
Das führt mich zu der Frage, was denn wirklich passiert, wenn die MFC stirbt (sprich nicht mehr supported wird). Da sie ja nur die WinApi kapselt und alle DLLs eh beim Visual Studio dabei sind dürfte es doch gar keine Rolle spielen, wenn ich halt partout dmmit weiterentwickeln will.
-
Warum ist QT denn dafür nicht in Ordnung? Da gibt es doch auch einen grafischen Editor für die GUI, damit es fix geht.
-
Longhorn basiert NICHT auf Win32 soweit ich weiss
dementsprechend wird es so sein das die platform zwar das laufen von win 32 systemen noch unterstuetzt - aber win32 wird spaetestens im OS nachher tot sein.Net ist das neue Framework - bzw .Net 2
du wirst also auf longhorn die alten win32 programme noch laufen lassen koennen
aber das wird sicher so sein das die Win32 Kompatiblitaet auf das .Net Framework zugreift. Also hast du wieder Overhead
na ja - bin ja gespannt wieviel von dem ganzen stimmt und wie sich der SQL Server im kernel benimmt
-
.Net 2 ??
-
ComeronPo schrieb:
.Net 2 ??
Die naechste Version von dotNET
Die hat dann eine Menge mehr am Kasten als dotNET 1.1 (das aktuelle)
Man muss .NET 1 also eine Art Beta-Version sehen, um die Leute langsam an .NET zu gewoehnen und noch die eine oder andere Aenderung fuer .NET 2 zu erkennen. Denn .NET 1.1 hat eigentlich keine Daseinsberechtigung - denn es bietet nichts, wofuer es nicht schon etablierte Technologien gibt. Aber wenn .NET 2 dann in Longhorn integriert ist, ist .NET auf einmal sehr wichtig.
-
Marc++us schrieb:
Zu C++ ist das noch nicht zu 100% raus, da MS lustigerweise den C++-Standard inzwischen mit dem VC7.1 besser abdeckt als jemals zuvor (und besser als jemand jemals erwartet hätte). Würden sie das tun, wenn sie C++ unter Windows eliminieren wollten?
vielleicht wollten sie ein paar leute in ihr lager hollen und haben sie mit iso98 gelockt oder sie hatten das die ganze zeit in der schublade und bevor sie es wegschmeissen wollen sie noch etwas geld machen
Marc++us schrieb:
Zur Zeit würde ich eine Oberfläche (nachdem Borland auch den Builder in den Ruhestand schicken wird) mit C# und .NET machen, wenn es für Windows sein soll.
meinst du in iso-c++ das backend und in c# die gui, beides verbunden durch COM? wird dadurch die gui nicht etwas zäher?
-
Warum soll QT (womit ich in der obengenannten Auswahl am meisten zu tun hab) nur unwesentlich besser sein als die MFC?
Ich finde die MFC um einiges umständlicher, und in QT kann ich einfach auch ohne Designer gute Oberflächen erstellen.
-
Selbes gillt imho auch für Gtkmm.
Da brauche ich keinen Meta-Compiler und kann auch den
Kompfort eines GUI-Designers genießen.
-
Ich denke, dass Marc++us absolut Recht hat. Möglichst wenig Aufwand in die GUI. Den geistigen Input in das Innenleben der Programme stecken. Beim Anwender spielt auch dort die Musik. Filme in Farbe sind oft schlechter als die alten Schwarzweiß-Schinken. Bei King Kong ist der erste Film immer noch der Beste.
-
Hallo!
(
C# ist in meinen Augen auch nur eine Kreuzung aus Delphi und C++ nach MS Vorstellungen.)
Das ist alles so ungewiss. Und deswegen habe ich jetzt auch angefangen WinAPI zu lernen. Da ist man unabhängig. Auch vom Compiler. Das ist in IMHO ein größes Problem der neuen "Sprachen". Delphi, C#, BASIC sind alle komerziell. C und C++ sind nicht aus kommerziellen Gründen entstanden. Das war eine ihrer Stärken.MFG, the flyingCoder.
-
flyingCoder schrieb:
(
C# ist in meinen Augen auch nur eine Kreuzung aus Delphi und C++ nach MS Vorstellungen.)C# ist ein Java-Clone mit einer stark verbesserten VCL als GUI.
Das ist alles so ungewiss.
Nein, nicht alles.
dotNET wird unter Windows der Standard fuer GUI Anwendungen werden, es sei denn Java liefert bis zum Longhorn-Release noch eine Sensation ab.Und deswegen habe ich jetzt auch angefangen WinAPI zu lernen.
WinAPI wird aber sterben, das ist gewiss.
Da ist man unabhängig.
Nein, warum? Mit der WinAPI bist du zwar Sprachunabhaengig, aber dafuer stark Plattform abhaengig.