wxWidgets reines C++?

What are the high-level assumptions or ground rules for the project?

* a clean public ISO-C++-interface, i.e. no macros or compiler specific extensions
* writing very good user documentation that helps beginners and professionals
* easy to build and use library
* Provide compiler independent build scripts (bjam)

Da kann man fröhlich drüber lachen. Das zu implementieren dürfte ein Kinderspiel sein. Nur holt man sich damit genau die Probleme wieder ins Boot, die mit Makros und den anderen Geschichten verhindert werden sollen. Letztlich eine Zeitverschwendung.

Dravere schrieb:

IchKaufeEinÜ_üüüü schrieb:

Wer oder was ist Artchi?

Ein Mensch mit einem solchen Nickname, der sich hier im Forum rumtreibt.

Meistens schreibt er als Unregistrierter. Die Nicks Hansi Hinterseher und Bulli fallen mir da ein.

basti33

altanativ schrieb:

Was würdet ihr einen "Anfänger" denn anstelle von wxWidgets empfehlen zu lernen?

gtkmm. Das ist schönes "reines" C++. Das einzige was da vielleicht etwas nervt ist, dass es unter Windows recht umständlich einzurichten ist.

Tachyon

basti33 schrieb:

altanativ schrieb:

Was würdet ihr einen "Anfänger" denn anstelle von wxWidgets empfehlen zu lernen?

gtkmm. Das ist schönes "reines" C++. Das einzige was da vielleicht etwas nervt ist, dass es unter Windows recht umständlich einzurichten ist.

Ich mag gtkmm zwar auch, aber "reines" C++ ist das nicht. Eher ein reiner C++-Wrapper um reinen C Code.

Dravere schrieb:

...Jedes wxWidgets Objekt (oder so gut wie jedes) hat automatisch eine Referenzzählung im Hintergrund. Das heisst damit allerdings, dass jedes Objekt auf den Heap muss, wenn man das Ding auf den Stack legt, kracht es gewaltig. Das soll eine "Vereinfachung" sein. Meiner Meinung nach eher für dümmliche Programmierer gedacht, dafür aber jegliche Kontrolle dem eigentlichen Programmierer weggenommen...

Sowas in der Art macht Qt im Normalfall leider auch. Es baut Parent-Child-Bäume auf, die (ich glaube beim töten von QApplication) beim Beenden automatisch wieder vom Heap genommen werden. Man kann Qt zwar auch irgendwie mit statischen Objekten betreiben, aber der Aufwand dafür ist recht groß.

basti33

Tachyon schrieb:

Ich mag gtkmm zwar auch, aber "reines" C++ ist das nicht. Eher ein reiner C++-Wrapper um reinen C Code.

Okay, das stimmt. Aber ich wollte hier eigentlich das ganze nur aus Sicht eines Anwenders betrachten. Und für die ist es ja reines C++, sprich sie müssen sich nicht mit Makros u.ä. beschäftigen. Dass das intern vllt. doch verwendet wird, braucht sie ja nicht zu kümmern...

MasterK

Tachyon schrieb:

Sowas in der Art macht Qt im Normalfall leider auch. Es baut Parent-Child-Bäume auf, die (ich glaube beim töten von QApplication) beim Beenden automatisch wieder vom Heap genommen werden. Man kann Qt zwar auch irgendwie mit statischen Objekten betreiben, aber der Aufwand dafür ist recht groß.

Nur wenn du ein Parent angibst. Übergibst du da NULL (was üblicherweise vorbelegt ist) passiert nix.
Gelöscht werden diese parent-child-bäume afaik beim löschen des parents. Was in meinen augen auch sinn macht.

Ich find Qt schon wirklich durchdacht und mMn mit die beste GUI (und vieles andere) -bibliothek die es für c++ gibt.

@MasterK
Was meinst du mir mMn?

Tyrdal

meiner Meinung nach

Tachyon

MasterK schrieb:

Nur wenn du ein Parent angibst. Übergibst du da NULL (was üblicherweise vorbelegt ist) passiert nix.

Und wo werden Widgets (z.B.) Buttons angezeigt, wenn sie keinen Parent haben? Duch addWidget, addLayout etc. werden die "geaddeten" Teile automatisch zu Kindern, und das Teil wo hinzugefügt wird automatisch zum Parent.
Oder was glaubtst Du, wieso man in den meisten Qt-Programmen zu keinem new ein delete sieht?

Zwei Dinge gefallen mir an Qt ganz gut. Zum einen die Doku, die ist wirklich klasse. Zum anderen das Aussehen der Programme. Mit anderen Toolkits (z.B. gtkmm unter Windows) brauchts relativ viel Gefummel, um das so hinzubekommen.
Der Rest ist eher mäßig. Schon der olle moc. Oder diese komischen Makros. Signals und Slots kann man auch mit reinem C++ realisieren. Auch der komische Signal-Dispatcher-Code, der aus dem moc heraus kommt ist ziemlich gräuslich.

MasterK

Tachyon schrieb:

Und wo werden Widgets (z.B.) Buttons angezeigt, wenn sie keinen Parent haben?

Widgets ohne parents sind automatisch normale fenster.

Tachyon schrieb:

Duch addWidget, addLayout etc. werden die "geaddeten" Teile automatisch zu Kindern, und das Teil wo hinzugefügt wird automatisch zum Parent.
Oder was glaubtst Du, wieso man in den meisten Qt-Programmen zu keinem new ein delete sieht?

QWidget hat kein addWidget, du gibts wenn schon dann beim erstellen den parent an:

QButton* button = new QButton(mainWindow)

Und das macht doch auch sinn. Warum sollte ich den button behalten wollen wenn das fenster welches den button enthält gelöscht wird? Im gegenteil, ich fänds extrem unnötig alle child-widgets von hand zu löschen.
Und das parent-widget kannst du ja wie gehabt von hand löschen wenn du das willst.

Edit:
meine aussage zu den parent-child-beziehungen bezog sich btw auf QObject, nicht auf QWidget.