Übersicht zu den Frameworks

maximAL schrieb:

schau dir lieber Qt an.

Seufz! Hast du meinen Post gelesen?
--> Native Widgets + modernes C++
Und die Liste auf kharchi.eu sagt, dass Qt beides nicht hat.

Außerdem gefällt mir das hier nicht:
[quote=http://kharchi.eu/wiki/doku.php?id=cpp:gui:libs]Einmal die kostenlose GPL-Variante für OpenSource-Projekte. Und für Closedsource-Projekte kann man eine kommerzielle Lizenz von Trolltech erwerben.[/quote]
Meine Programme sind nie Open Source.

P.S.: Die Native-Widgets-Sache ist für mich noch wichtiger als das moderne C++-Design, das heißt, das einzige, was ich von der Liste neben VCF unter Umständen noch benutzen würde, wäre wxWidgets.

maximAL

Originalposter schrieb:

maximAL schrieb:

schau dir lieber Qt an.

Seufz! Hast du meinen Post gelesen?
--> Native Widgets + modernes C++
Und die Liste auf kharchi.eu sagt, dass Qt beides nicht hat.

Außerdem gefällt mir das hier nicht:

http://kharchi.eu/wiki/doku.php?id=cpp:gui:libs]Einmal die kostenlose GPL-Variante für OpenSource-Projekte. Und für Closedsource-Projekte kann man eine kommerzielle Lizenz von Trolltech erwerben.

Meine Programme sind nie Open Source.

P.S.: Die Native-Widgets-Sache ist für mich noch wichtiger als das moderne C++-Design, das heißt, das einzige, was ich von der Liste neben VCF unter Umständen noch benutzen würde, wäre wxWidgets.

hast du dir diese auflistung mal genauer angesehen? der punkt "modernes c++" ist für den anus, Qt hat da wohl nur deshalb ein nein stehen, weil es noch eigene prä-prozessoren benutzt. ich kann dir versichern, dass Qt äusserst modern designed ist (wie genau du das definierst steht wieder auf einem anderen blatt).
desweiteren wird zwar nicht nativ gerendert, aber wenigstens sieht es "fast" nativ aus, kein vergleich mit GTK oder ähnlichem schrott.

wenn du natürlich (kommerzielle?) closed source software schreiben willst, hast du natürlich tatsächlich ein problem. wobei es da noch irgendwelche ausnahmeregelungen gibt, die ich mir allerdings auch noch nicht genauer angesehen habe.

Badestrand

Originalposter schrieb:

Meine Programme sind nie Open Source.

P.S.: Die Native-Widgets-Sache ist für mich noch wichtiger als das moderne C++-Design, das heißt, das einzige, was ich von der Liste neben VCF unter Umständen noch benutzen würde, wäre wxWidgets.

Mir geht's da ähnlich, ich schwanke immer zwischen VCF und wxWidgets, wobei mir keines der beiden komplett gefällt. Welches der beiden du nun nimmst, musst du entscheiden. Ich würde vorschlagen, du überfliegst von beiden die Tutorials um den Stil kennenzulernen, schnupperst in die Klassenliste rein und (für mich eins der wichtigsten Dinge) probierst mal beide GUI-Designer aus.

QTs GUI-Designer gefällt mir wesentlich besser, als der von VCF/wxWidgets, die kommerzielle QT-Lizenz soll aber >2500$ (weiß nicht mehr genau, wieviel, jedenfalls über 2500$) kosten.

Generell missfällt mir bei den C++-GUI-Kits, dass die nie "lightweight" sind, man muss meist seine ganze Applikation danach ausrichten (mindestens gefühlt), anstatt das GUI-Kit wie jede andere Lib einfach einzubinden.

edit: Finde grad den VCF-Builder-Download gar nicht mehr

Nexus

Vor diesem Problem stehe ich auch. Ich kann mich nicht wirklich entscheiden, welches GUI-Framework ich nehmen sollte.

Ich hab jetzt mal mit VCF angefangen, weit bin ich allerdings noch nicht gekommen. Und für so modern, wie das C++ von VCF bezeichnet wird, halte ich es bei weitem nicht. Erstens mal benutzt es auch Heap-Allokationen und einen Reference Counter - ist in dieser Hinsicht also nicht besser als wxWidgets.

Zweitens ist der Programmierstil meines Erachtens zu sehr an andere Sprachen angelehnt. Irgendwie hab ich das Gefühl, VCF wurde nach dem Motto "je mehr OOP, desto besser" entwickelt - was teilweise, gerade in C++, zu merkwürdigen Ansätzen führt. Beispielsweise finde ich es ungewohnt, dass man gezwungen wird, von Klassen abzuleiten, die virtuellen Funktionen zu überschreiben und trotzdem die der Basisklasse noch aufzurufen. Oder dass es eine statische Memberfunktion main() gibt. Oder Init- und Clone-Methoden.

Und sämtliche Klassen von VCF sind riesig, grossteils mit hässlichen Methoden wie addRef() , copy() , init() , clone() und ähnlichen überfüllt. Wieso kann man nicht einfach in C++ programmieren, Stack-Deklarationen zulassen, Reference Counting ganz wegwerfen? Wenn man so erpicht auf Garbage Collection ist, kann man ja Smart Pointer benutzen. Aber nein, diese Arbeit muss einem auch "abgenommen" werden. Diese Bevormundung regt mich schon ein wenig auf. Wie Badestrand sagt, muss man seine ganze Applikation und seinen Programmierstil nach VCF ausrichten, weil man derart in seiner Freiheit eingeschränkt wird.

Viertens ist VCF einfach gigantisch. Es ist ja gut, dass es so viele Bereiche abdeckt, aber mir würde ein GUI-Toolkit mehr als reichen. Gerade die selbstdefinierten Dinge wie Smart Pointer und Container finde ich relativ überflüssig. Vor allem verliert man bei so einem grossen Framework schnell die Übersicht. Das beginnt bereits mit der Dokumentation, die ich teilweise für ziemlich irreführend halte...

Naja, ich hab wie gesagt noch nicht gross mit VCF gearbeitet, aber das ist so mein erster Eindruck. Ich bin ehrlich gesagt ziemlich enttäuscht, zumal auf der Homepage grosse Versprechen gemacht werden. Aber in dieser Hinsicht bin ich auch wenig über den kleinen Bekanntheitsgrad der Bibliothek verwundert...

audacia

Nexus schrieb:

Und für so modern, wie das C++ von VCF bezeichnet wird, halte ich es bei weitem nicht. Erstens mal benutzt es auch Heap-Allokationen und einen Reference Counter - ist in dieser Hinsicht also nicht besser als wxWidgets.

?

Wie funktioniert denn Polymorphie mit stack-allozierten Objekten?

Nexus schrieb:

Zweitens ist der Programmierstil meines Erachtens zu sehr an andere Sprachen angelehnt. [...]

Um es auf den Punkt zu bringen: das VCF hat - freilich ohne eine entsprechende Reverenz - sehr viele der Konzepte aus der VCL von Delphi/C++Builder übernommen und in nativem C++ nachzubilden versucht. Eigentlich eine nette Idee, aber die Umsetzung ist, wie du ja ganz richtig feststellst, etwas fragwürdig.

Meine Begeisterung für all diese Toolkits hält sich in Grenzen. Es ist erfahrungsgemäß oftmals effektiver, den Anwendungskern in portablem C++ zu halten und systemspezifische UIs mit den jeweils am besten geeigneten Toolkits zu entwickeln. Das fördert die Kapselung des Projektes - ein von allem UI-Code isolierter Anwendungskern läßt sich von einem Konsoleninterface ansteuern, mithin einfach testen -, es verringert die Komplexität des visuellen Frontends (keine systemspezifischen #ifdefs) und stellt sicher, daß sich z.B. das Windows-UI auch nach Windows anfühlt - unter anderem, da es all die systemspezifischen UI-Eigenheiten voll ausnutzen kann.

Nexus

audacia schrieb:

Wie funktioniert denn Polymorphie mit stack-allozierten Objekten?

So:

Base a;
Derived b;

Base* p = &a;
Base* q = &b;

p->Func();
q->Func();

Aber es geht mir ja nicht primär darum. Man könnte sich womöglich einige Polymorphie sparen. Was mich eher stört, ist das Reference Counting und die allgemeine Einschränkung von Seiten der Bibliothek. Kann man mit Reference Counting überhaupt den Todeszeitpunkt der Objekte auswählen?

audacia schrieb:

Meine Begeisterung für all diese Toolkits hält sich in Grenzen. Es ist erfahrungsgemäß oftmals effektiver, den Anwendungskern in portablem C++ zu halten und systemspezifische UIs mit den jeweils am besten geeigneten Toolkits zu entwickeln.

Ich habe mir auch überlegt, mit der Zeit einen Wrapper um das Framework zu bauen, um damit "normal" C++ programmieren zu können... Vorausgesetzt natürlich, dass ich bei VCF bleibe.

Aber wie sieht das mit anderen GUI-Toolkits aus? Bei GTKmm soll ja angeblich auch modernes C++ verwendet werden... Wird da mehr von den Versprechungen gehalten?

audacia

Nexus schrieb:

audacia schrieb:

Wie funktioniert denn Polymorphie mit stack-allozierten Objekten?

So: [...]

Daran ist nichts polymorph. (Theoretisch könnte ein Compiler sogar alle virtuellen Funktionsaufrufe wegoptimieren.)

Und ohne Polymorphie via Heap-Allokation funktioniert Persistenz, also z.B. das Laden eines Fensters aus einer Ressourcendatei, nicht mehr; folglich müssen Formulardesigner, wie für WinForms oder Swing üblich, anstelle einer Ressourcendatei Code generieren, und das ist bei C++ nicht eben trivial.
Überdies haben Ressourcen auch noch andere Vorteile, z.B. lassen sie sich leichter internationalisieren.

Nexus

audacia schrieb:

Daran ist nichts polymorph.

Weshalb nicht?

audacia schrieb:

(Theoretisch könnte ein Compiler sogar alle virtuellen Funktionsaufrufe wegoptimieren.)

Eigentlich darf nur an Stellen optimiert werden, die die Semantik des Programmes nicht verändern.

Sonst stimme ich dir schon zu. Aber die Polymorphie ist auch nicht immer notwendig. Wenn man ein Objekt auf dem Stack erstellt, weiss man, welche Funktion die richtige ist. Nicht immer hat man Basisklassenzeiger, die auf unterschiedlichste Klassen zeigen können. Und das stört mich ja eben: Dass man nicht mal die Möglichkeit erhält, auf dem Stack zu arbeiten. Wenn man auf dem Heap arbeiten will, soll man das gerne tun, aber da nimmt man auch die Speicherverwaltung in die Hand. Und mit Smart Pointers ist das nicht einmal anspruchsvoll.

audacia

Nexus schrieb:

Weshalb nicht?

Eben deshalb, weil ein Compiler sämtliche Aufrufe virtueller Funktionen statisch binden kann.

Nexus schrieb:

Eigentlich darf nur an Stellen optimiert werden, die die Semantik des Programmes nicht verändern.

... selbstverständlich auch unter Berücksichtigung dieser Regel.

Aber die Diskussion ist hinfällig, da wir uns in dem Punkt ja einig zu sein scheinen: mit stackbasierten Objekten sind viele Aspekte der Polymorphie nicht effektiv nutzbar.

Nexus schrieb:

Und das stört mich ja eben: Dass man nicht mal die Möglichkeit erhält, auf dem Stack zu arbeiten. Wenn man auf dem Heap arbeiten will, soll man das gerne tun, aber da nimmt man auch die Speicherverwaltung in die Hand. Und mit Smart Pointers ist das nicht einmal anspruchsvoll.

Wo ist nun der große Unterschied zwischen interner Referenzzählung à la COM und einem Smart-Pointer?

Gerade aufgrund der Existenz der Smart-Pointer ist es doch eigentlich unerheblich, ob ein Objekt auf dem Heap erstellt werden muß oder nicht.

Der Rock schrieb:

Gibt es eine aktuelle Liste, auf der die ganzen C++-GUI-Frameworks aufgelistet sind und auf der man mal übersichtlich die einzelnen Eigenschaften der Frameworks (Betriebssystem, native Controls ja/nein etc.) sehen kann, um sie zu vergleichen?

Nimm Linux.