4. Unterschiede zu MFC

Unterschiede zu MFC

  • C

    @Artchi: Glaub der wichtigste Vorteil bezüglich WinAPI ist eigentlich (und der wurde glaube ich noch nicht oder nur implizit erwähnt): Sie ist verdammt schnell.

    Mal noch ne kleine Frage (an Dich 😉 ):
    Du kennst Dich ja anscheinend sehr mit Frameworks aus... 👍 :
    Ähm welches Framework würdest Du mir empfehlen, dass einerseits möglichst guten C++ Support hat (Exceptions, Vererbung), anderseits kostenlos ist, möglichst plattform-übergreifend arbeitet (Windows, Linux, Mac ... reicht ja eigentlich) und, das wichtigste: Auch eigene Styles zu lässt.

    Haste da vllt n Tipp/Empfehlung ? Ich danke schonmal 😉 .

    PS: Hab mir Deine Seite auch schonmal angeguckt - echt gelungen 👍 .

    0
  • A

    Glaub der wichtigste Vorteil bezüglich WinAPI ist eigentlich (und der wurde glaube ich noch nicht oder nur implizit erwähnt): Sie ist verdammt schnell.

    Hem, das widerspricht aber nicht einer Kapselung. Soll heißen, wenn ich die Win32-API kapsel, wird trotzdem die Win32-API genutzt. Wieso sollte hier ein Performancenachteil entstehen? Eine Kapselung versteckt nur den Aufruf, es ersetzt nicht die API. Wenn ich ein Fenster in Java erstelle, wird am Ende auch nur ein Win32-Fenster erzeugt, Java kapselt das ganze nur. Gut, ob Java der Flaschenhals ist, ist eine andere Geschichte. 😉 Aber das Fenster selbst, ist das gleiche wie in einem C-Programm. In C++ hast du durch Inlining im optimalen Fall 0% Performance-Verlust. Lass es einen Taktzyklus mehr für die vtable sein. Naja, weiß nicht wo da eine direkte Win32-API-Nutzung schneller sein soll.

    Ähm welches Framework würdest Du mit empfehlen, dass einerseits möglichst guten C++ Support hat (Exceptions, Vererbung), anderseits kostenlos ist, möglichst plattform-übergreifend arbeitet (Windows, Linux, Mac ... reicht ja eigentlich) und, das wichtigste: Auch eigene Styles zu lässt.

    Haste da vllt n Tipp/Empfehlung ? Ich danke schonmal

    Oh, das ist leider sehr schwer. Leider suche ich selbst noch nach so einem Framework. 😃 Selbst die Java-Welt hat mittlerweile mehrere GUI-Libs, obwohl es dort eine Standard-Lib namens Swing gibt. Z.B. setzen immer mehr Java-Eclipse-Projekte auf SWT. Weil SWT andere Vorteile ggü. Swing hat. Aber viele benutzen Swing, weil SWT ein paar andere Nachteile hat.

    Ich kann dir sagen, welche Libs ich nicht empfehlen würde, weil nicht in deine Forderungen passen: wxWidgets, Ultimate++ (keine Buildfiles im Lieferumfang!), VCL, MFC, WTL, VACA, FLTK und vielleicht noch FOX. Bleibt nicht mehr viel übrig: gtkmm und VCF. Wobei nur gtkmm von beiden eigene lokale Themes erlaubt. VCF aber wiederrum globale Themes nutzt. Schau in meine Übersicht, was von beiden für dich besser ist. Aber gtkmm ist am Ende halt doch verbreiteter.

    Deshalb habe ich die Übersicht auch geschrieben: es kann einem schon mal einen Knoten im Gehirn bringen. "Ein verwirrendes Wirrwar!" (von Dan Akkroid aus dem Film Evolution) :p

    0
  • A

    Artchi schrieb:

    Ich kann dir sagen, welche Libs ich nicht empfehlen würde, weil nicht in deine Forderungen passen: wxWidgets, Ultimate++ (keine Buildfiles im Lieferumfang!), VCL, MFC, WTL, VACA, FLTK und vielleicht noch FOX.

    Könntest du das vielleicht im einzelnen näher begründen? MFC ist klar, aber der Rest würde mich näher interessieren...

    0
  • A

    Wenn man sich die Anforderungen von FreakCoder anschaut, und dann meine Bemerkungen auf meiner GUI-Übersicht, wird einem klar, warum soviele Kandidaten ausscheiden. Alle reinen Win-GUI-Libs fliegen schon mal raus, weil Multiplatform gefordert war. Bleiben noch viele übrig, aber erfüllen selten die eigentlich selbstverständlichen C++-Features wie Namespaces, Exceptions, RTTI, Enums, Konstanten usw.

    wxWidgets und FOX arbeiten noch unnötigerweise mit Makros, an viel genutzten Stellen. Werden einfach nicht modernisiert, zumindest nicht kurzfristig. U++ ist dummerweise nur mit TheIDE nutzbar, obwohl es eigentlich gut ist. 👎 FLTK 2 wird zwar modernisiert, hat aber eine sehr nüchternes und unaktuelles Widget-Design (Win98-Style!) und man kann es auch nicht wirklich ändern. Wer unbedingt Win32-Controls haben will, hat eh nur wxWidgets und VCF zur Auswahl, wobei VCF die viel modernere C++-Lib von beiden ist. gtkmm ist auch modern, zeichnet seine Widgets aber selbst, aber man kann wenigstens das Design der Widgets umschalten.

    Kann man aber alles auf meiner Übersicht nachlesen. 😃 Wenn auch nicht immer ganz so spektakulär wie in diesem Posting. 😉

    0
  • A

    Deine Übersicht ist sehr gut, danke für den Link 😉

    Artchi schrieb:

    wxWidgets und FOX arbeiten noch unnötigerweise mit Makros, an viel genutzten Stellen. Werden einfach nicht modernisiert, zumindest nicht kurzfristig. U++ ist dummerweise nur mit TheIDE nutzbar, obwohl es eigentlich gut ist. 👎 FLTK 2 wird zwar modernisiert, hat aber eine sehr nüchternes und unaktuelles Widget-Design (Win98-Style!) und man kann es auch nicht wirklich ändern. Wer unbedingt Win32-Controls haben will, hat eh nur wxWidgets und VCF zur Auswahl, wobei VCF die viel modernere C++-Lib von beiden ist. gtkmm ist auch modern, zeichnet seine Widgets aber selbst, aber man kann wenigstens das Design der Widgets umschalten.

    Danke für deine Ausführungen 😉

    (
    Wenn du erlaubst, noch ein paar Ergänzungen zu deiner Übersicht aus Sicht eines VCL-Benutzers:
    - der Quelltext der VCL ist verfügbar und bei Turbo C++ dabei
    - zumindest in bezug auf deine Definition ("Makrohölle") ist die VCL durchaus gutes C++-Design. Und auch ansonsten würde ich sie als gutes objektorientiertes Design bezeichnen - eben in Pascal. Namespaces, Exceptions, RTTI, Enums etc. werden natürlich verwendet 😉
    - es gibt eine VCL für Win32 und für .NET (Versionen für .NET CF und WPF sind in Arbeit)
    )

    Bzgl. FLTK: Nichts gegen Win98-Style! 😉

    Deine Beschreibungen zur VCF klingen gut. Die werde ich mir mal ansehen...

    0
  • C

    Artchi schrieb:

    Glaub der wichtigste Vorteil bezüglich WinAPI ist eigentlich (und der wurde glaube ich noch nicht oder nur implizit erwähnt): Sie ist verdammt schnell.

    Hem, das widerspricht aber nicht einer Kapselung. Soll heißen, wenn ich die Win32-API kapsel, wird trotzdem die Win32-API genutzt. Wieso sollte hier ein Performancenachteil entstehen? Eine Kapselung versteckt nur den Aufruf, es ersetzt nicht die API.[...]

    Ähm naja wenn man die MFC einbindet, bindet man meistens auch Dinge ein, die man nie benötigt. Dadurch wird das Programm unnötig 'klobig' 😉 .

    Ansonsten, erstmal danke für die Ausführungen! Sieht ja stark danach aus, als würde ich mir das gtkmm-Framework genauer ansehen 😉 .

    0
  • A

    der Quelltext der VCL ist verfügbar und bei Turbo C++ dabei

    Ja, aber ist doch kein Opensource, oder? Von der MFC ist der Source auch einsehbar. Aber ich darf ihn nicht verändern und weiter geben. Ich darf ihn nur einsehen. Wenn dagegen die VCL-Lizenz erlaubt, den Source frei zu verändern und weiter zu geben, wäre es Opensource und ich ändere es entsprechend um. Wenn nicht, bitte einen besseren Begriff nennen. Wird schwierig. 😉

    - zumindest in bezug auf deine Definition ("Makrohölle") ist die VCL durchaus gutes C++-Design. Und auch ansonsten würde ich sie als gutes objektorientiertes Design bezeichnen - eben in Pascal. Namespaces, Exceptions, RTTI, Enums etc. werden natürlich verwendet

    Ich habe spezielle Compiler-Befehle gesehen. Läuft die VCL auch unter MSVC und Mingw? Weiterhin war mir in Erinnerung (kann auch anders sein), das Attribute public sind?

    0
  • T

    CodeFinder schrieb:

    Ähm naja wenn man die MFC einbindet, bindet man meistens auch Dinge ein, die man nie benötigt. Dadurch wird das Programm unnötig 'klobig' 😉 .

    das ist bei c++ oft so.
    einmal std::string benutzt oder 'cout' und schon wird die .exe fetter...

    0
  • C

    ten schrieb:

    CodeFinder schrieb:

    Ähm naja wenn man die MFC einbindet, bindet man meistens auch Dinge ein, die man nie benötigt. Dadurch wird das Programm unnötig 'klobig' 😉 .

    das ist bei c++ oft so.
    einmal std::string benutzt oder 'cout' und schon wird die .exe fetter...

    Das hat aber was mit Template-Instantiierung zu tun... . Das gibts ja bei der MFC (leider ?! 😃 ) nicht...

    0
  • T

    CodeFinder schrieb:

    ten schrieb:

    CodeFinder schrieb:

    Ähm naja wenn man die MFC einbindet, bindet man meistens auch Dinge ein, die man nie benötigt. Dadurch wird das Programm unnötig 'klobig' 😉 .

    das ist bei c++ oft so.
    einmal std::string benutzt oder 'cout' und schon wird die .exe fetter...

    Das hat aber was mit Template-Instantiierung zu tun... . Das gibts ja bei der MFC (leider ?! 😃 ) nicht...

    doch. mfc hat auch ein paar templates mit dabei.

    0
  • C

    ten schrieb:

    doch. mfc hat auch ein paar templates mit dabei.

    Echt ? Welche (z.B.) ?

    0
  • T

    CodeFinder schrieb:

    ten schrieb:

    doch. mfc hat auch ein paar templates mit dabei.

    Echt ? Welche (z.B.) ?

    einige von den collections, CArray, CList usw...

    0
  • A

    Ja, z.B. CString. 😃 Allerdings ist CString nicht mehr in der MFC sondern ATL drin.

    0
  • C

    Hm na ok, ich benutze weder das eine, noch das andere 😃 (und wahrscheinlich bald gtkmm 😃 ).

    0
  • T

    CodeFinder schrieb:

    (und wahrscheinlich bald gtkmm)

    dann sehen deine programme bald so hässlich aus wie 'the gimp' 😉

    0
  • C

    ten schrieb:

    CodeFinder schrieb:

    (und wahrscheinlich bald gtkmm)

    dann sehen deine programme bald so hässlich aus wie 'the gimp' 😉

    Hm wieso, sieht doch gar nicht so schlecht aus...:
    http://www.myopensource.org/screenshots/gimp.png
    http://wingimp.hp.infoseek.co.jp/gimp/images/aboutgimp-0-screenshot.jpg
    http://developer.gimp.org/screenshots/gimp-misc.png
    http://www.paw.hi-ho.ne.jp/mazi-deka/gazou/gimp_linux800.gif
    EDIT: Hier noch mehr: http://www.gimp.org/screenshots/

    Oder was meinst Du ?

    0
  • T

    CodeFinder schrieb:

    Oder was meinst Du ?

    genau das. 1000 fensterchen die zusammenhangslos auf dem bildschirm kleben.
    ich finde sowas blöd und unübersichtlich, aber ist natürlich geschmackssache...

    0
  • A

    Aber was hat das mit gtkmm zu tun? Wie man Fenster und Widgets anordnet ist doch eine ganz andere Sache. Win32-API kennt nicht mal Splitviews (geteilte Fenster), trotzdem wird hier nicht von Win32-API abgeraten. Ist doch irgendwie unlogisch.

    0
  • ?

    Artchi schrieb:

    Ja, aber ist doch kein Opensource, oder? Von der MFC ist der Source auch einsehbar. Aber ich darf ihn nicht verändern und weiter geben. Ich darf ihn nur einsehen. Wenn dagegen die VCL-Lizenz erlaubt, den Source frei zu verändern und weiter zu geben, wäre es Opensource und ich ändere es entsprechend um. Wenn nicht, bitte einen besseren Begriff nennen. Wird schwierig. 😉

    Weitergeben darf man ihn AFAIK nicht, aber es ist erlaubt, den Quelltext zu verändern und statisch ins Programm einzubinden (die VCL-Libraries neu zu erstellen ist nicht möglich -> DLL Hell).

    Artchi schrieb:

    Ich habe spezielle Compiler-Befehle gesehen. Läuft die VCL auch unter MSVC und Mingw? Weiterhin war mir in Erinnerung (kann auch anders sein), das Attribute public sind?

    Nein; da die VCL in Delphi geschrieben ist und diese Sprache Dinge wie Properties und Closures (aka Delegates) unterstützt, die es in C++ (noch) nicht gibt, gibt es für diese compilerspezifische Erweiterungen (__property, __closure), die AFAIK nur der BCC unterstützt. Dafür kann man Delphi- und C++-Code in einem Projekt verwenden.
    Als public deklarierte Attribute sind mir noch nicht begegnet; du meinst vermutlich die öffentlichen Properties, die sich wie Attribute vehalten, aber technisch gesehen Funktionsaufrufe sind.
    Insofern ist die VCL vielleicht kein "gutes C++", aber aus objektorientierter Sicht durchaus gut gestaltet. (Und ehrlich gesagt vermisse ich durch die speziellen Schlüsselwörter hinzugefügte Funktionalität in Standard-C++ andauernd. Vielleicht wird das mit C++ 0x besser?)

    Solange ich keine plattformunabhängigen GUIs erstellen muß, habe ich keine Probleme, die VCL zu benutzen. Alles, was von der GUI unabhängig ist, versuche ich möglichst in standardkonformem C++ zu schreiben. So kann ich den Teil im Zweifelsfall auch mal mit einem anderen Compiler benutzen. Aber für den GUI-Teil bietet die VCL mir entschieden zu viele Möglichkeiten, um sie nicht zu nutzen 😉

    0
  • Mod

    audacia|off schrieb:

    Weitergeben darf man ihn AFAIK nicht, aber es ist erlaubt, den Quelltext zu verändern und statisch ins Programm einzubinden (die VCL-Libraries neu zu erstellen ist nicht möglich -> DLL Hell).

    Man darf auch die DLLs verändern muss dann aber einen neuen Namen vergeben. Die makefiles in der MFC sind für diese Eventualität vorbereitet.
    Wir haben unseren eigenen Build der MFC-DLLs und geben den auch entsprechend weiter. Die DLLs heißen dann natürlich anders.

    Wir haben also unsere ganz private DLL-Hölle... 🤡

    0
Anmelden zum Antworten