Wofür steht eigentlich wxWidgets?

stefan2008

Ich weis, Widgets steht für Fenster. Aber wofür steht wx? Ich merke, bei wxWidgets gibt es Datentypen wie wxChar, wxString usw. Sind diese Datentypen vergleichbar mit den Standarddatentypen oder brauchen sie mehr speicher?

Gruß,
Stefan

zwutz

w steht für Windows, x für X (die beiden Plattformen, für die wx ursprünglich entwickelt wurde

In der Regel wird bei derartigen Frameworks empfohlen, die Framework-eigenen Datentypen den Standarddatentypen vorzuziehen. Sie bieten mehr Features (z.B. Konvertierung von und zu Zahlen in einer String-Klasse) und werden natürlich innerhalb des Frameworks ständig benötigt. Noch dazu enthalten sie diverse Ausnahmebehandlungen und Modifikationen, die vor allem die plattformunabhängigkeit garantieren und vor groben Schnitzern bewahren.
Für den Fall, dass man doch mal die Standard-Typen braucht, bieten diese Klassen auch entsprechende Umwandlungsmethoden an

frenki

Ich persönlich würde empfehlen ausserhalb der GUI keine der wx-eigenen Datetypen zu verwenden.

Zum einen sollte man sowieso stets seine Daten von der GUI trennen, zum anderen erleichtert es das Schreiben von Unit-Tests ohne GUI.

phlox81

frenki schrieb:

Ich persönlich würde empfehlen ausserhalb der GUI keine der wx-eigenen Datetypen zu verwenden.

Zum einen sollte man sowieso stets seine Daten von der GUI trennen, zum anderen erleichtert es das Schreiben von Unit-Tests ohne GUI.

Würde ich auch empfehlen. Zu mal sich vieles durch boost ersetzen oder ergänzen lässt. Und auf keinen Fall sollte man die wx eigenen Containerklassen nutzen, die std container sind da doch überlegen.

zwutz schrieb:

In der Regel wird bei derartigen Frameworks empfohlen, die Framework-eigenen Datentypen den Standarddatentypen vorzuziehen. Sie bieten mehr Features (z.B. Konvertierung von und zu Zahlen in einer String-Klasse) und werden natürlich innerhalb des Frameworks ständig benötigt. Noch dazu enthalten sie diverse Ausnahmebehandlungen und Modifikationen, die vor allem die plattformunabhängigkeit garantieren und vor groben Schnitzern bewahren.
Für den Fall, dass man doch mal die Standard-Typen braucht, bieten diese Klassen auch entsprechende Umwandlungsmethoden an

Das ist aber alles so nicht korrekt. Der Grund, warum die ganzen Frameworks eigene Typen haben, ist doch historisch bedingt. Damals, als sie entstanden, gab es noch keine C++-Norm, und jeder COmpiler-Hersteller hatte sein eigenes C++-Süppchen gekocht. Also wurden eigene Typen definiert und je nach Compiler per Präprozessor entsprechend abgebildet. So konnte man irgendwie eine "Norm" innerhalb eines Frameworks auf mehreren Compilern und Plattformen sicherstellen.

Würde man heute ein neues Framework entwickeln, wären solche Sachen wie wxString, wxChar usw. totaler Blödsinn. Denn es gibt ja heute eine C++-Norm die diese Typen definiert. Bei elementaren Typen kann man vielleicht noch sowas wie int32 definieren, falls man 100% einen 32bit-Typ benötigt.

Ich würde die wx-Typen nur dann benutzen, wenn ich nicht drum rum komme.

phlox81

Bulli schrieb:

zwutz schrieb:

In der Regel wird bei derartigen Frameworks empfohlen, die Framework-eigenen Datentypen den Standarddatentypen vorzuziehen. Sie bieten mehr Features (z.B. Konvertierung von und zu Zahlen in einer String-Klasse) und werden natürlich innerhalb des Frameworks ständig benötigt. Noch dazu enthalten sie diverse Ausnahmebehandlungen und Modifikationen, die vor allem die plattformunabhängigkeit garantieren und vor groben Schnitzern bewahren.
Für den Fall, dass man doch mal die Standard-Typen braucht, bieten diese Klassen auch entsprechende Umwandlungsmethoden an

Das ist aber alles so nicht korrekt. Der Grund, warum die ganzen Frameworks eigene Typen haben, ist doch historisch bedingt. Damals, als sie entstanden, gab es noch keine C++-Norm, und jeder COmpiler-Hersteller hatte sein eigenes C++-Süppchen gekocht. Also wurden eigene Typen definiert und je nach Compiler per Präprozessor entsprechend abgebildet. So konnte man irgendwie eine "Norm" innerhalb eines Frameworks auf mehreren Compilern und Plattformen sicherstellen.

Würde man heute ein neues Framework entwickeln, wären solche Sachen wie wxString, wxChar usw. totaler Blödsinn. Denn es gibt ja heute eine C++-Norm die diese Typen definiert. Bei elementaren Typen kann man vielleicht noch sowas wie int32 definieren, falls man 100% einen 32bit-Typ benötigt.

Ich würde die wx-Typen nur dann benutzen, wenn ich nicht drum rum komme.

Gerade eine gute Stringklasse ist immer gut, da std::string etwas mager ist. Gerade was Unicodeunterstützung angeht.

Xantus

will wxWidgets nicht sowieso auf std::string umstellen bzw. wxString fast 100% zu std::string machen (bzw. hat dies bereits getan) ?

aus http://docs.wxwidgets.org/trunk/overview_string.html#overview_string_comparison :

# Efficiency: Since wxWidgets 3.0 wxString uses std::string (UTF8 mode under Linux, Unix and OS or std::wstring (MSW) internally by default to store its constent. wxString will therefore inherit the performance characteristics from std::string.
# Compatibility: This class tries to combine almost full compatibility with the old wxWidgets 1.xx wxString class, some reminiscence to MFC CString class and 90% of the functionality of std::string class.