Welches Framework(?) ist für mich geeignet
-
Also, wenn mich das heute (2004) jemand fragt, lautet meine Antwort sicherlich anders als noch vor 2 oder 3 Jahren... damals hätte ich ohne Zögern die VCL genannt.
Aber nun? Betrachten wir die Lage im kommerziellen Lager:
MFC - ist bewährt und man kennt die zahlreichen Nachteile inzwischen zur Genüge. Nur machen wir uns nichts vor, für die in aktuellen Anwendungen notwendigen GUI-Gimmicks bringt sie einfach zu wenig Hilfsmittel mit... selbst einfache Dinge wie ein Bild in einem Button oder farbige Edit-Boxen rutschen ruckzuck in SendMessage-Aufrufe und WinAPI ab. Ist bei dem herrschenden Zeitdruck nicht vertretbar. Außerdem nicht mehr wirklich weiterentwickelt von MS. VCL - war die ganze Zeit der Traum für jeden C++ler, der die MFC kannte. Schnell, zahlreiche Einstellmöglichkeiten und fast immer ausreichend für alle Anforderungen einer modernen GUI. Leider nun von Borland selbst im Stich gelassen und eigentlich abgekündigt. .NET - für C++ nicht wirklich brauchbar, da die ganzen integrierten Tools vom VStudio und der GUI-Designer alle auf C# abzielen und C++ (auch als managed C++) nicht wirklich unterstützen. Außerdem kann man nicht wirklich C++ programmieren, sondern bekommt managed C++, keine Standalone-Exe mehr. Ändert sich vielleicht noch im Laufe der nächsten Zeit, aber im Moment keine glückliche Lösung. Visual Basic und ActiveX kombiniert mit MFC - erscheint mir noch eine ganz interessante Lösung zu sein, wenn man mit VB6 grafische Control-Elemente komplexen Verhaltens unter VB als ActiveX erstellt, und diese dann in eine MFC-Anwendung einbettet. VB6 bringt eine reichhaltigere Gestaltungsmöglichkeit für die Control-Elemente mit als die MFC, Geschwindigkeitsargumente sind nicht stichhaltig, da bei GUIs die CPU-Zeit von der grafischen Darstellung gefressen wird, nicht von der Parameterübergabe. Erlaubt außerdem recht effektive Zerlegung der Projekte in Komponenten. Komplexe Control-Elemente lassen sich damit in wenigen Stunden entwerfen und einbinden. Dumm aber, daß auch VB6 nicht mehr wirklich auf der Produktpalette steht, VB.net ist kein Ersatz für diese spezielle Anwendung. Sicherlich aber für MFC zur Zeit die beste Lösung. [Hinweis: statt VB lässt sich das ActiveX auch mit Delphi realisieren] QT - etabliert und lange Zeit im Schattendasein, zumindest unter Windows. Hat den Vorteil gewisser Plattformunabhängigkeit (was man nicht immer braucht), hat sich in Bezug auf den GUI-Designer auch enorm weiterentwickelt. Lizenzkosten im kommerziellen Umfeld sicherlich nicht ganz so dramatisch. Leider wenig Literatur dafür, wenige Tutorials, wenig Infos dazu. Empfinde ich als Nachteil. Look&Feel der Anwendungen leider nicht ganz so, wie das Windows-konform ist. Kann für bestimmte Anwendungen problematisch werden. wxWindows, GTKmm - ähnlich QT, teilweise andere Mächtigkeit. Hauptproblem sehe ich bei allen vor allem die Informationslage - man kann nicht mehr einfach überall fragen "wie geht das mit diesem Control"? Zu wenige Leute kennen es.Eigentlich war das noch nie so bescheiden wie heute.
-
Marcus du machst mir nicht wirklich Mut
Jetzt weiß ich erst recht nicht mehr was ich nehmen soll. Es sieht so aus, als
wäre GTKmm und für den Rest andere Libs? Wenn ich alle Dateien in nem Verzeichnis
auslesen möchte, müsst ich dann trotzdem noch die Winapi nehmen, das will ich ja
möglichst vermeiden. Oder etwas in die Registry schreiben, die Zwischenablage,
hm mehr fällt mir grad nicht ein, bin mir aber sicher es gibt noch mehr
-
Ich kann dir nur wxWindows empfehlen, denn wxWindows ist neben der VCL die wohl vollständigste und funktionsreichste Bibliothek, die es gibt. Eine RAD/IDE gibt es in Form von VisualWx bereits für Windows. Mit der nächsten Version vom Borland C++BuilderX wird es dann auch eine gute RAD/IDE für Linux und Solaris geben.
Der enzige Nachteil ist momentan, dass es nicht viele Infos, Tuts, Manuals oder gar Bücher über wxWindows gibt. Ich denke aber, dass sich das in naher Zukunft ändern wird.
-
@SirLant
mach dir nicht so viele Sorgen, dass du etwas falsches oder zu viel lernst. Du wirst in dem Laufe deines Programmiererleben noch mit so vielen Biblihoteken arbeiten müssen. Deswegen such dir das aus, was die einfach am besten gefällt wenn du die API anguckst. Du stehst ja vor keiner ultimativen Entscheidung@Marc++us
Leider wenig Literatur dafür, wenige Tutorials, wenig Infos dazu.
das stimmt so nicht! Mittlerweile gibt es genügend Foren, Tutorials und Bücher zu Qt. Ich glaub nicht, dass da ein enormer Mangel existiert.
@Sovok
die MFC kostet auch Geld
-
SirLant schrieb:
Wenn ich alle Dateien in nem Verzeichnis
auslesen möchte, müsst ich dann trotzdem noch die Winapi nehmen, das will ich ja
möglichst vermeiden.Dafür kann man auch Boost.FileSystem nehmen. Boost würde ich mir in jedem Fall mal angucken, auch wenn es dir für UI nicht viel hilft: http://www.boost.org
-
@Marc++us: Bis auf einen Punkt stimme ich dir uneingeschränkt zu: VB6 und MFC ist keine gute Idee. VB6 wird von MS nicht mehr weiterentwickelt (=> VB.net). Daher sollte man entweder C# oder QT benutzen.
-
-
Dann sag doch mal wo man sie umsonst beziehen kann.
-
hmpf läd dir c++ builder x personal runter, da ist das dabei^^
-
vc++ hätt ich auch so gekauft
qt kostet deutlich mehr und man bekommt nich eine der besten entwicklungsumgebungen dazubtw. was is managed c++
-
-
IDEsupport is currently lacking, compared to other managed languages, since there's little or no designer support (but Everett will change this).
abgesehn davon hört sichs doch gut an
wann wird des gefixt?
-
2003, wenn Everett rauskommen wird?
Das ist einfach der Codename für MSVC7.1/2003, das schon länger in den Läden steht und (uA) einen Windows-Forms-Designer hat.
Viel Spaß macht das damit aber IMHO nicht. Der Designer fühlt sich selbst auf schnellen Kisten eher bloatig an und der erzeugte Quellcode ist nicht gerade dekorativ...
BTW: MS arbeitet schon fleißig an Managed C++s "Nachfolger", CLI/C++. Das ist eine standardisierte und *schöne* Möglichkeit, C++ und .NET miteinander zu verwenden. Dauert aber bestimmt noch ewig
-
dann bleibt halt erstmal mfc
-
mfc jetzt anfangen zu lernen lohnt sich erst recht nicht mehr. MS wird die nicht weiter unterstützen. Das ist verschwendete Zeit. Wobei man sich dann zusätzlich noch mit einem der ekelhaftesten C++ APIs rumschlagen muss.
btw. mit dotNET ist kein Platform unabhängiges GUI programmieren möglich! Die GUI und Datenbank Sachen sind proprietäre Erweiterungen zu dotNET und nicht im EMCA/ISO Standard enthalten AFAIK. Da bleibt dir dann auch nur GTK#!
-
Moment, da habe ich eine Frage zu: gtk# basiert doch aber auch auf den .NET-Forms, oder implementieren die den Fensterkernel selbst (und dann für jede Plattform)?
-
GTK# ist wohl nur ein binding zur GTK Library. Auf WinForms arbeitet das aber nicht!
-
I see
-
@Gtk# The current release is 0.15
das ding in nem ernsthaften projekt einzusetzen is selbstmord
mit einem der ekelhaftesten C++ APIs
is geschmacksache... ich mag mfc. ich hätt zwar nix gegen was aktuelleres. aber es gibt ja noch nix
-
@Gtk# The current release is 0.15
das ding in nem ernsthaften projekt einzusetzen is selbstmord
das zeigt deine Unwissenheit. Die Versionsnummer sagt so nichts über die Qualität des Produktes aus! Gerade im OpenSource Bereich wachsen die Versionsnummern extrem langsam. Du findest ja sogar schone eine Liste von Projekten, die die API benutzen.
ich hätt zwar nix gegen was aktuelleres. aber es gibt ja noch nix
nichts von MS. Ansonsten gibt es viele aktuellere Frameworks, die viel mehr C++ sind. (MFC könnte man ja fast als C bezeichnen)
siehe gtkmm, boost etc.