Unterschiede zu MFC
-
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...
-
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
.
-
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?
-
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...
-
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...
-
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.
-
ten schrieb:
doch. mfc hat auch ein paar templates mit dabei.
Echt ? Welche (z.B.) ?
-
CodeFinder schrieb:
ten schrieb:
doch. mfc hat auch ein paar templates mit dabei.
Echt ? Welche (z.B.) ?
einige von den collections, CArray, CList usw...
-
Ja, z.B. CString.
Allerdings ist CString nicht mehr in der MFC sondern ATL drin.
-
Hm na ok, ich benutze weder das eine, noch das andere
(und wahrscheinlich bald gtkmm ).
-
CodeFinder schrieb:
(und wahrscheinlich bald gtkmm)
dann sehen deine programme bald so hässlich aus wie 'the gimp'
-
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 ?
-
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...
-
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.
-
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
-
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...
-
@ten:
Artchi schrieb:
Aber was hat das mit gtkmm zu tun? Wie man Fenster und Widgets anordnet ist doch eine ganz andere Sache.
Eben
, 
.
