Welches Framework(?) ist für mich geeignet



  • Die Super-Bibliothek für alles, gibt es jedenfalls nicht.

    .Net kommt aber schon sehr nahe hin. Allerdings würde ich es nicht mit C++ benutzen.



  • 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.



  • kingruedi schrieb:

    @Sovok
    die MFC kostet auch Geld 🙄

    seit wann?
    hab ich was verpasst?



  • 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 dazu

    btw. 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!

    http://gtk-sharp.sourceforge.net/



  • 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


Anmelden zum Antworten