wxWidgets vs Qt

ScyllaIllciz

Android geht auch c++ mit dem Andorid NDK

Ich habe hier auf meinem Android Smartphone Qt am Laufen

Dean schrieb:

Der Weg geht da ganz klar richtung Browser als Schnittstelle zwichen den Plattformen und Systemen.
...
Das ist auch das was die PC Welt erwarten wird.

Ich finde solch subjektiven Prognosen einfach bescheuert.

@scheiss qt
Einen unqualifizierteren Namen hast du wohl nicht gefunden.

Einfach mal, weil Qt so mies ist, und sowieso nur auf frickeligen Linux-Heimrechnern läuft:
http://blogs.kde.org/node/4474
Ich weiß auch schon, was jetzt von Dean kommt: Qt verbrät so viel Leistung, dass man ne riesige Kühleinheit braucht, um die CPU vorm Durchschmoren zu bewahren

Qt ist das mit abstand beste Framework, dass jemals von Menschenhand gebaut worden ist ...

Dank ausgeklügelten konzepten wie moc, wird der Makrowahn um noch eine Ebene höher geschraubt.

qt hasser schrieb:

Qt ist das mit abstand beste Framework, dass jemals von Menschenhand gebaut worden ist ...

Dank ausgeklügelten konzepten wie moc, wird der Makrowahn um noch eine Ebene höher geschraubt.

Du musst es ja nicht nehmen, viele andere tun es gern und haben keine Problem den MOC zu verstehen und zu gebrauchen.

ScyllaIllciz

Ich verstehe das ganze "moc ist scheiße" gar nicht. Ich habe mir noch nie Gedanken darüber machen müssen, weil alles reibungslos funktiert. Was soll das also. Nehmt Qt oder laßt es! Ich will auf Qt nicht verzichten, weil es (für mich) keine vernünftige Alternative gibt.

ScyllaIllciz schrieb:

Ich verstehe das ganze "moc ist scheiße" gar nicht. Ich habe mir noch nie Gedanken darüber machen müssen, weil alles reibungslos funktiert.

Schonmal versucht verschachtelte Q_OBJECT- Klassen zu verwenden? Wird nicht klappen Bin noch recht neu in Qt, wusste das nicht und brauchte eine geschachtelte Klasse. Stattdessen musste ich das ganze durch friend-class-rumgemurkse loesen...

Irgendwo in der Qt-Dokumentation gibts eine fette Liste an Beschraenkungen, die man durch den moc hat. Das ist dann schon wirklich kein echtes C++ mehr und genau deswegen regen sich viele (einschl. mir) auf.

ChuckNorris schrieb:

wusste das nicht und brauchte eine geschachtelte Klasse. Stattdessen musste ich das ganze durch friend-class-rumgemurkse loesen...

Was hat "geschachtelte Klasse" mit "friend" zu tun?!? Wenn du den Zugriff der einschließenden Klasse auf private/protected-Elemente der eingeschlossenen Klasse meinst, muss ich dich an den Standard verweisen:

11.8 Nested classes
1
[class.access.nest]
The members of a nested class have no special access to members of an enclosing class, nor to classes or
functions that have granted friendship to an enclosing class; the usual access rules (clause 11) shall be
obeyed. The members of an enclosing class have no special access to members of a nested class; the usual
access rules (clause 11) shall be obeyed. [Example:
class E {
  int x;
  class B { };
  class I {
    B b;                // error: E::B is private
    int y;
    void f(E* p, int i)
    {
      p->x = i;         // error: E::x is private
    }
  };
  int g(I* p)
  {
    return p->y;        // error: I::y is private
  }
};
—end example]

Du wirst also auch bei nested classes nicht um friend herum kommen.

Irgendwo in der Qt-Dokumentation gibts eine fette Liste an Beschraenkungen, die man durch den moc hat. Das ist dann schon wirklich kein echtes C++ mehr und genau deswegen regen sich viele (einschl. mir) auf.

"fette Liste" ist arg übertrieben. Assistant aufmachen, "moc" suchen, Unterpunkt "limitations". Sind 7 Punkte, von denen mir persönlich bisher noch keiner in die Quere gekommen ist.

Zu deiner Aussage:

Schonmal versucht verschachtelte Q_OBJECT- Klassen zu verwenden? Wird nicht klappen

Das ist arg verallgemeinert, vielmehr sagt die Doku:

Nested Classes Cannot Have Signals or Slots

Ein "nested QWidget" mit selbst überschriebenen virtuellen Funktionen -> geht.
Ein QObject mit properties -> geht.
Es werden eben auch keine bereits in der Basisklasse existierenden Signals/Slots weggeschnitten.

no friend schrieb:

ChuckNorris schrieb:

wusste das nicht und brauchte eine geschachtelte Klasse. Stattdessen musste ich das ganze durch friend-class-rumgemurkse loesen...

Was hat "geschachtelte Klasse" mit "friend" zu tun?!? Wenn du den Zugriff der einschließenden Klasse auf private/protected-Elemente der eingeschlossenen Klasse meinst, muss ich dich an den Standard verweisen:

Seltsam. Ich hab mir den Standard zwar noch nie durchgelesen, aber ich hatte schwoeren koennen, dass das problemlos geht ...
Trotzdem zeigt folgender Test, dass ein Zugriff unter gewissen Umstaenden trotzdem moeglich ist (getestet mit QtSDK-MinGW und MSVC10):

...

class A
{
public:
	A(int h) : a(h) {}
private:
	int a;
	class B
	{
	public:
		int Geta(const A& a) const
		{
			return a.a;
		}
	};
public:
	int Geta() const
	{
		B b;
		return b.Geta(*this);
	}
};

int main(int argc, char** argv)
{
	QApplication app(argc, argv);

	A a(2);
	int test = a.Geta();

	...
}

ChuckNorris schrieb:

Trotzdem zeigt folgender Test, dass ein Zugriff unter gewissen Umstaenden trotzdem moeglich ist

Deine "gewissen Umstände" sind "B::Geta() ist public" - also nichts aufregendes, kein Hack oder etwas weswegen man "friend" bräuchte. OK, class A::B ist private, aber von außen greifst du ja nicht drauf zu und A hat auf alles "in sich" Zugriff, auch auf private Member oder auf private nested classes.

no friend schrieb:

ChuckNorris schrieb:

Trotzdem zeigt folgender Test, dass ein Zugriff unter gewissen Umstaenden trotzdem moeglich ist

Deine "gewissen Umstände" sind "B::Geta() ist public" - also nichts aufregendes, kein Hack oder etwas weswegen man "friend" bräuchte. OK, class A::B ist private, aber von außen greifst du ja nicht drauf zu und A hat auf alles "in sich" Zugriff, auch auf private Member oder auf private nested classes.

A::B hat dann ja aber auch Zugriff auf die privaten Member von A anscheinend. Das waere eben sonst nur mit friend moeglich.
Uebrigens funktioniert das ganze auch, wenn du A::B public machst.
Dass heisst, es wuerde dann auch folgendes gehen:

A a(4);
	A::B b;
	int test = b.Geta(a);

Obwohl A::a privat ist.
Widerspricht das nicht dem Text-Auszug aus dem Standard?
Bin jetzt etwas verwirrt.

Bei meinem Problem damals ging es um folgendes:
Ich hatte eine QWidget-Klasse und brauchte eine kleine QThread-Klasse, die ich auch nur fuer diese QWidget-Klasse brauchte (und auch nur innerhalb der QWidget-Klasse). Um herauszufinden, wann der Thread beendet wurde brauchte einen Slot fuer das Signal finished() (deswegen war ja auch keine geschachtelte Klasse moeglich). In diesem Slot habe ich dann eine private Variable von der QWidget-Klasse aendern muessen.
Das ganze waere dann wohl anstatt friend auch mit einer geschachtelten Klasse moeglich gewesen, wenn moc es nicht verbieten wuerde.

Obwohl A::a privat ist.

Ach - merde, hab ich übersehen.
Im übrigen hab ich mich verhauen
Im Kapitel zur Access Control steht nicht alles... Das was wir wollen steht direkt unter "Nested class Declarations":

9.7 Nested class declarations
1
[class.nest]
A class can be defined within another class. A class defined within another is called a nested class. The name of a nested class is local to its enclosing class. The nested class is in the scope of its enclosing class.
Except by using explicit pointers, references, and object names, declarations in a nested class can use only type names, static members, and enumerators from the enclosing class.

Darunter ist dann ein Beispiel, das genau den deinigen Fall beinhaltet - und erlaubt!

Ich würde aber in dem von dir beschriebenen Fall nicht auf nested classes setzen. Der Thread den du wolltest ist ein Implementierungsdetail und kein Teil der eigentlichen Widget-Klasse. Deine Threadklasse kannst du wunderbar in der .cpp deklarieren und definieren, in der du deine eigene QWidget-Klasse implementierst. Allein aus OOP-Sicht macht es also keinen Sinn, die Thread-Klasse als Teil der Widget-Klasse anzugeben.
Und nur eine nested-Klasse verwenden, weil du dir dadurch einen friend sparst ist auch nicht so...

Wusste ich doch, dass mich mein Wissen nicht taeuscht ^^
Trotzdem bin ich jetzt etwas verwirrt:

class E {
  int x;
  class B { };
  class I {
    B b;                // error: E::B is private
    int y;
    void f(E* p, int i)
    {
      p->x = i;         // error: E::x is private
    }
  };
  int g(I* p)
  {
    return p->y;        // error: I::y is private
  }
};

Wieso "error: E::x is private"? Das muss doch eigentlich gehen? Wieso nicht? Ich komm grad nicht drauf..

Ich würde aber in dem von dir beschriebenen Fall nicht auf nested classes setzen. Der Thread den du wolltest ist ein Implementierungsdetail und kein Teil der eigentlichen Widget-Klasse. Deine Threadklasse kannst du wunderbar in der .cpp deklarieren und definieren, in der du deine eigene QWidget-Klasse implementierst. Allein aus OOP-Sicht macht es also keinen Sinn, die Thread-Klasse als Teil der Widget-Klasse anzugeben.
Und nur eine nested-Klasse verwenden, weil du dir dadurch einen friend sparst ist auch nicht so...

So hab ichs dann auch gemacht (naja hab schon ne extra Header-Datei angelegt).
Es ging nicht um das sparen eines friends. Ich dachte mir nur, dass eine geschachtelte Klasse fuer den Fall sauberer waere, weil ich die Klasse ja sonst nicht mehr brauche (nur innerhalb der QWidget-Klasse). Aber naja, das ist letztendlich glaub ich auch nur Geschmackssache - und beim Design gibts ja immer verschiedene Meinungen.

no friend schrieb:

11.8 Nested classes
1
[class.access.nest]
The members of a nested class have no special access to members of an enclosing class, nor to classes or
functions that have granted friendship to an enclosing class; the usual access rules (clause 11) shall be
obeyed. The members of an enclosing class have no special access to members of a nested class; the usual
access rules (clause 11) shall be obeyed. [Example:
class E {
  int x;
  class B { };
  class I {
    B b;                // error: E::B is private
    int y;
    void f(E* p, int i)
    {
      p->x = i;         // error: E::x is private
    }
  };
  int g(I* p)
  {
    return p->y;        // error: I::y is private
  }
};
—end example]

Konnte nun soeben herausfinden, dass dieser Code falsch ist.
p->x = i ist erlaubt sowie auch B b;
Deine Quelle scheint somit fehlerhaft zu sein

Korrekt steht es im C++ Standard so drin:

class E {
  int x;
  class B { };
  class I {
    B b;                // ok: E::I can access E::B
    int y;
    void f(E* p, int i)
    {
      p->x = i;         // ok: E::I can access E::x
    }
  };
  int g(I* p)
  {
    return p->y;        // error: I::y is private
  }
};

Es gibt 2 verschiedene: Den "alten" C++03 und den "neuen" C++11.
Mein quote stammt aus dem C++03er. Ich hatte ihn von hier.
Und nachdem ich nochmal drüber geschaut habe, ist es nach C++03 tatsächlich verboten, auf die privaten Member der einschließenden Klasse zuzugreifen. Da die meisten Compiler C++11 noch nicht voll unterstützen, gehe ich davon aus, dass die meisten noch nach C++03 coden.
In C++11 hat sich hier aber scheinbar tatsächlich was geändert.

no friend schrieb:

Es gibt 2 verschiedene: Den "alten" C++03 und den "neuen" C++11.
Mein quote stammt aus dem C++03er. Ich hatte ihn von hier.
Und nachdem ich nochmal drüber geschaut habe, ist es nach C++03 tatsächlich verboten, auf die privaten Member der einschließenden Klasse zuzugreifen. Da die meisten Compiler C++11 noch nicht voll unterstützen, gehe ich davon aus, dass die meisten noch nach C++03 coden.
In C++11 hat sich hier aber scheinbar tatsächlich was geändert.

Jepp, so ist es.
Deswegen klappts auch mit meinen Compilern, da dieses Feature aus C++11 schon (laenger(?)) uebernommen wurde.
Bin trotzdem ueberrascht, dass das im alten Standard nicht ging.

Hier die Aenderung: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45

Wurde im neuen C++ Standard also so geaendert:

A nested class is a member and as such has the same access rights as any other member.

Change

B b; // error: E::B is private

to

B b; // Okay, E::I can access E::B

Change

p->x = i; // error: E::x is private

to

p->x = i; // Okay, E::I can access E::x

Gut, dass das "Raetsel" geloest ist

johan

Ich habe eine generelle Frage zur Multiplattformfähigkeit von wdWidgets versus Qt.

EDIT: Frage hat sich erübrigt, habe die Antwort hier gefunden. Zitat:

"wxWidgets verzichtet aber weitgehend auf das Zeichnen eigener Controls, sondern versucht die nativen Widgets eines Betriebs/Desktopsystems (Win32/WinApi,GTK+ 1/2, Xlib)zu wrappen, und ermöglicht damit das Schreiben plattformunabhängiger Programme, welche möglichst das Look & Feel der jeweiligen Plattform bieten."
[EDIT END]

Es gibt ja das 2 Möglichkeiten: So wie es z. B. YACL (wird leider nicht mehr weiterentwickelt), die ersten Versionen der StarDivision-Klassenbibliothek oder (im Java-Bereich) die AWT-Klassen machten:

Die einzelnen Widgets des Multiplattformsystems rufen direkt die entsprechenden Widgets der nativen GUI des Betriebssystems/Oberfläche auf (Typ 1).

Vorteil: Die Anwendung ist von einer nativen App für die Oberfläche nicht zu unterscheiden.

Nachteil: Man hat nur den gemeinsamen Nenner, wenn das Programm wirklich plattformunabhängig sein soll. So unterstützte YACL zwar unter Windows und OS/2 Comboboxen, unter MOTIF gab es die nicht (KDE und GTK waren damals noch nicht so weit, das sie von YACL unterstützt wurden). Wenn man also Comboboxen verwendete, musste man die für MOTIF irgendwie "nachbauen".

Zweite Möglichkeit: So wie es Qt schon immer macht.

Die einzelnen Widgets werden selbst gezeichnet, mit den primitiven Grafikroutinen des Betriebssystem und dessen Oberfläche (Typ 2).

Vorteil: Man hat auf jedem Betriebssystem identische Oberflächenelemente/Widgets.

Nachteil: Die erzeugten Anwendungen haben nicht mehr das native Aussehen des Betriebssystems. Kann zwar durch Style-Libs ganz gut versteckt werden. Aber spätestens beim nächsten Betriebssystem-Update, bei dem sich auch der Stil ändert, sieht man es.

Ist wxWidget vom Typ 1 oder Typ 2? Falls vom Typ 2, kennt jemand noch eine Multiplattform-Klassenbibliothek vom Typ 1, die aktuell auch noch gepflegt wird (und die wie YACL auch ohne spezielle C++-Erweiterungen, wie z. B. bei Qt, auskommt)?