MFC -> tod
-
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.
-
Warum wird die WinAPI sterben? Auf ihr baut doch alles auf!?
Ich habe mir C# nicht tiefgehender angeguckt. Deswegen frage ich: Ist es nicht so, dass C# dem C Grundsatz, die Sprache möglichst klein zu halten, widerspricht?mfg ...
-
flyingCoder schrieb:
Warum wird die WinAPI sterben? Auf ihr baut doch alles auf!?
MS gibt in Win64 einfach die nativen WinAPI-Schnittstellen für die ganzen neuen Funktionen einfach nicht mehr bekannt. Dann kannst Du zwar noch Win32-Progs erstellen, aber nicht mehr die Features von Win64 nutzen. Und damit kannst Du keine aktuellen Programme erstellen => finish.
flyingCoder schrieb:
Ist es nicht so, dass C# dem C Grundsatz, die Sprache möglichst klein zu halten, widerspricht?
Zwei Dinge:
-
C-Grundsätze gelten nicht für C#, da dies eine andere Sprache ist.
-
Die Sprache C# ist relativ knapp gehalten, besitzt halt viele OO-Features und Schlüsselwörter dafür, aber eigentlich nur das was man dafür braucht. So schlank wie C ist sie nicht, aber das geht ja auch gar nicht.
-
-
Kane schrieb:
Selbes gillt imho auch für Gtkmm.
Da brauche ich keinen Meta-Compiler und kann auch den
Kompfort eines GUI-Designers genießen.Full Ack; Glade(mm)+GTK(mm) ist eine sehr elegante Möglichkeit auch komplexe GUIs zu erstellen.
-
Bis zum Longhorn release lohnt es sich auf alle Fälle noch die Winapi anzuschauen,
da es bis dorthin noch ein Weilchen dauert und dann dauert es nochmal eine lange
Zeit bis man wirklich auf NET2 umstellen kann ohne WinXp,Win2k,... auszusperren.
Von daher mach ich mir da wenig Sorgen, bis in 3Jahren kann ich noch fleißig mit
der Winapi arbeiten und dann schau ich mir vllt. mal NET2 an wenn ich auf
Longhorn aufrüsten sollte, bis jetzt hört sich das ja noch gut an, wenn MS da
nicht wieder Müll wie bei XP einbaut, nen OS das ohne Anfrage ins Inet geht und
ne Firewall eingebaut hat, erweckt auf mich kein Vertrauen, ich will die gesamte
Kontrolle über den Netzverkehr haben um mich sicher zu fühlen.
-
"MS gibt in Win64 einfach die nativen WinAPI-Schnittstellen für die ganzen neuen Funktionen einfach nicht mehr bekannt."
Das kommt alles irgendwie raus. Dann blüht Win64API richtig auf.
