wxWidgets vs Qt

[Sonja Saubertochter]

Dean schrieb:

Der Vorteil einer Terminalsitzung ist, dass es egal ist welche API / OS am Terminalserver arbeitet. Warm sollte ich ein Programm was auf einem Terminalserver läuft ohne Winapi entwickeln?

Wir reden aneinander vorbei. Terminal == Konsole == "TUI" - zwar bietet die WinAPI nette Funktionen zum Formatieren, wer plattformunabhängig bleiben will sollte es wenigstens gut wegkapseln.
Mehr wollte ich nicht sagen. Eine Client-Anwendung für einen Terminalserver meinte ich nicht.

Und wo ist wirklich Plattformunabhängigkeit wichtig? Wo gibt es Firmennetzwerke die Linux als Client verwenden ? Seltenst Mac. Der Webbrowser oder Terminalsitzung sind da die besten Schnittstellen.

Das interessiert hier doch gar nicht! Ich sage "Wer plattformunabhängig will" und du meinst "wo ist das interessant" - völlig andere Diskussion.

Mobile / Embeddet, da ist derzeit c++ nicht die beste Wahl. Und auch hier ist der Browser wieder die beste Schnittstelle.

Browser + Addin + (gescriptete?) Software sind besser als ein dünnes C++-Programm?

Qt nicht überladen? Qtlist Operator[] ?

QList ist nicht das ws du meinst -> Doku.
QList ist was spezielles, wenn du std::list meinst -> QLinkedList.

ODBC MSSQL und Qt sind Dinge die nicht zusammenpassen bzw auch nur rudimentär supported wird.

Aha! Du verallgemeinerst die Kombi "ODBC MSSQL Qt Stored Procedure" in ein "Qt Stored Procedure".
Ich hatte bisher noch nichts mit MS SQL zu tun - vllt. liegts daran.
Da dir aber auch die Funktionsweise von QList nicht bekannt ist, denke ich du bist nie wirklich tiefer in Qt eingestiegen, könnte also auch ein Anwendungsfehler sein...

[RHBaum]

Die Mfc hat aber auch Vorteile, sollte man nicht unerwaehnt lassen.

- Ich kann multithreaded direct auf die MessageQueues schiessen. unter QT, no way.
- Performancemaessig ist die Qt ziemlich ... naja sie ist sehr abstract. Eigene Queue ueber die nativen Windows Message-Queues. Aber wie scho gesagt, Performance spielt ned die absolute rolle.
- die MFC iss nur nen duenner Wrapper, die Winapi ist pures C. Bei Modularer Programmierweisse, also eigene Dlls mit C-Schnittstellen, tut man sich etwas leichter. Nen QString und nen QWidget linearisierst ned soo schnell wie nen Wrapper der um TChar und um HWND aufgebaut ist.

Wie gesagt, es kommt auf den anwendungsfall an.
Bei tools, zeugs was ich unter kontrolle habe, etc, nehm ich auch gern die QT. Weil performanceanforderung sind meist normal, also gering ... und es sind kaum Kollisionen zu erwarten.
bei "groesseren projekten" "kotzt" ich oft auch über die Qt Abhaengigkeiten.

Wir arbeiten mit der Main App auf Qt 4.6.1 ... und liefern unser Setup abgesichert auch mit den 4.6.1er qt dlls aus ... und das plugin vom zulieferer xyz will ploetzlich eine 4.6.4 ?

Arbeite mal in groesseren Modularen Projekten, dort wirst Du QT-Freiheit, überhaupt freiheit von jeglicher 3d. party dynamischen lib echt schätzen lernen.

Ciao ...

[jaf]

Dean schrieb: "My Way: -Plattformunabhängig = Silverlight"

Ich bin neugierig: Hast Du das schon mal _ernsthaft_ unter Linux versucht? [Moeglicherweise gar auf einer nicht-Novell-Distribution?]

[Dean]

Soweit mir bekannt ist, gibt es für Silverlight mit Linux auch eine Möglichkeit mit Moonlight. Unabhängig von Silverlight/MS gibt es da diverse Anbieter und unterschiedliche Web Frameworks.

Der Browser und ein Terminalsserver sind die besten Möglichkeiten in heterogenen Netzwerken Plattformprobleme zu lösen.

@Sonja Saubertochter Terminalserver != Terminalzugriff über SSH an einer Linux Kiste / TTY. Schau die mal Citrix oder MS TS an. Eine App mit Windows Api und über RDP oder vergleichbar wird eine Sitzung hergestellt. Auf dem Client muß quasi gar kein OS ( boottp ), ein Terminalserver Client muß vorhanen sein da reicht auch ein Thinclient, der Zugriff ist auch von Linux/Mac möglich. Ähnlich dem X Protokoll.

Und ja unabhängig der Qlinkedlist ist Qt einfach überladen, bei MFC liegt die Problematik weniger an der Arbeit mit der MFC als im Lernumfang und nicht oder kaum vorhandener Literatur.

[Dean]

Sonja Saubertochter schrieb:

Dean schrieb:

Mobile / Embeddet, da ist derzeit c++ nicht die beste Wahl. Und auch hier ist der Browser wieder die beste Schnittstelle.

Browser + Addin + (gescriptete?) Software sind besser als ein dünnes C++-Programm?

C++ auf einem Smartphone?

RIM/Blackberry = Java (Micro Edition)
Android = java
WP7 = C#
Palm = Web OS / HTML 5
Symbian = noch C++ bald C# da es auf Nokia Handys durch WP7 ersetzt wird.
Apple IOS = Objektive c

Der Weg geht da ganz klar richtung Browser als Schnittstelle zwichen den Plattformen und Systemen. Ein Appp für alle Plattformen separat schreiben?

Das ist auch das was die PC Welt erwarten wird.

[firefly]

Dean schrieb:

Sonja Saubertochter schrieb:

Dean schrieb:

Mobile / Embeddet, da ist derzeit c++ nicht die beste Wahl. Und auch hier ist der Browser wieder die beste Schnittstelle.

Browser + Addin + (gescriptete?) Software sind besser als ein dünnes C++-Programm?

C++ auf einem Smartphone?

RIM/Blackberry = Java (Micro Edition)
Android = java
WP7 = C#
Palm = Web OS / HTML 5
Symbian = noch C++ bald C# da es auf Nokia Handys durch WP7 ersetzt wird.
Apple IOS = Objektive c

Der Weg geht da ganz klar richtung Browser als Schnittstelle zwichen den Plattformen und Systemen. Ein Appp für alle Plattformen separat schreiben?

Das ist auch das was die PC Welt erwarten wird.

Android geht auch c++ mit dem Andorid NDK

[ScyllaIllciz]

Android geht auch c++ mit dem Andorid NDK

Ich habe hier auf meinem Android Smartphone Qt am Laufen

[Wurst]

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.

[Blubb]

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 hasser]

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.

[Wurst]

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.

[ChuckNorris]

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.

[no friend]

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.

[ChuckNorris]

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();

	...
}

[no friend]

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.

[ChuckNorris]

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.

[no friend]

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...

[ChuckNorris]

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.

[ChuckNorris]

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
  }
};