if (char == ?
-
Juhu, endlich einer der es versteht
std::string verwende ich nicht, da ich an einer eigenen Klasse arbeite (wofür ich u.a. das strlen verwende). Meine Klasse soll (vorerst) Unicode, ISO/IEC 8859 und ASCII unterstützen.
Weiß zufällig jemand, welches Format wchar_t verwendet? UTF-16?
-
Hi!
Das kommt ganz auf die Situation an. Die Länge eines String Literals ist ziemlich sicher mit strlen schneller zu ermitteln. Das liegt einfach daran, dass Compiler diese Funktion idR intrinsic implementiert haben. Und wenn er optimiert, strlen sozusagen schon zur Compilezeit ausführen kann.
Das funktioniert aber auch nur bei statischen Stringwerten. std::string wiederrum cached die Länge des Strings und kann somit u.U. schnellere Ergebnisse bringen.
grüße
-
Neku schrieb:
Weiß zufällig jemand, welches Format wchar_t verwendet? UTF-16?
Das ist vollkommen Plattform-, bzw. Compilerabhängig. Am besten nimmst du einfach einen Integertyp. Was spricht dagegen, deinen neuen String von std::string abzuleiten? Die "Ist-ein" Beziehung ist hier ja wohl mal so gut wie sonst nirgends erfüllt. Ich mache das zumindest so (arbeite gerade an einer ähnlichen Sache).
-
Ich mag std nicht.
wchar_t muss ich hier und da verwenden, um z.B. Dateiaktionen durchzuführen (Windows unterstützt ja Unicode-Dateinamen, wie das bei Linux ist weiß ich nicht).
-
Neku schrieb:
Ich mag std nicht.
Warum programmierst du dann C++?
Neku schrieb:
wchar_t muss ich hier und da verwenden, um z.B. Dateiaktionen durchzuführen (Windows unterstützt ja Unicode-Dateinamen, wie das bei Linux ist weiß ich nicht).
Wie gesagt, was wchar_t genau ist, ist dem Compilerhersteller vorbehalten, hauptsache es passt ein erweiterter Zeichensatz rein. MinGW unterstützt wchar_t nicht, deshalb benutz ich es nie und weiß nicht, wie der Linux-gcc das handhabt.
Was die Dateinamen angeht musst du unterscheiden. AFAIK benutzt Windows UTF-16 (das veraltete(!) Encoding, dass alle anderen einschränkt) und Linux UTF-8. Beides ist Unicode, aber nicht ohne Umwandlung kompatibel zueinander.
-
.filmor schrieb:
Neku schrieb:
Weiß zufällig jemand, welches Format wchar_t verwendet? UTF-16?
Das ist vollkommen Plattform-, bzw. Compilerabhängig. Am besten nimmst du einfach einen Integertyp. Was spricht dagegen, deinen neuen String von std::string abzuleiten? Die "Ist-ein" Beziehung ist hier ja wohl mal so gut wie sonst nirgends erfüllt. Ich mache das zumindest so (arbeite gerade an einer ähnlichen Sache).
Auch wenn ich immer dafür bin die STL zu verwenden. Von std::string ableiten ist kein guter Gedanke.
Neku schrieb:
Ich mag std nicht.
wchar_t muss ich hier und da verwenden, um z.B. Dateiaktionen durchzuführen (Windows unterstützt ja Unicode-Dateinamen, wie das bei Linux ist weiß ich nicht).Was hast du gegen die STL. Die Klassen sind grandios und sollten, da im C++ Standard enthalten, auch verwendet werden.
C Funktionen im C++ Code kann zwar mal vorkommen sollte aber vermieden werden und ist, wie ich meine, (meist) kein besonders guter Stil.grüße
-
David_pb schrieb:
Auch wenn ich immer dafür bin die STL zu verwenden. Von std::string ableiten ist kein guter Gedanke.
Warum? Falls es an daran liegt, dass std::string ein typedef ist, dann sollte er halt von basic_string<char> ableiten. Er kann auch einen string als Member verwenden, nur halt kein komisches Array.
-
.filmor schrieb:
Neku schrieb:
Ich mag std nicht.
Warum programmierst du dann C++?
Weil es Klassen, Templates u.a. ermöglicht - frag nicht so blöd ... C++ besteht nicht nur aus der STL!
std::basic_string<uint16>? Würg...
.filmor schrieb:
AFAIK benutzt Windows UTF-16 (das veraltete(!) Encoding, dass alle anderen einschränkt) und Linux UTF-8.
Wieso denn bitte "veraltet"? UTF-32 (welches Linux glaube ich verwendet) verbraucht viel zu viel Speicher.
-
http://de.wikipedia.org/wiki/Unicode_Transformation_Format#UTF-16
Linux verwendet UTF-8 oder ISO oder ASCII, aber auf keinen Fall UTF-32 als Standardkodierung. Das wird sowieso nur intern im Speicher für kurze Strings verwendet, da es einen gewissen Geschwindigkeitsvorteil gegenüber den anderen Kodierungen aufweist.
Neku schrieb:
.filmor schrieb:
Neku schrieb:
Ich mag std nicht.
Warum programmierst du dann C++?
Weil es Klassen, Templates u.a. ermöglicht - frag nicht so blöd ... C++ besteht nicht nur aus der STL!
Nicht direkt unverschämt werden. Die Standardbibliothek ist essentieller Bestandteil der Sprache C++.
C++ ist schon lange nicht mehr nur "C mit Klassen", bzw. "C mit Klassen und einigen anderen praktischen Spielzeugen".
-
.filmor schrieb:
http://de.wikipedia.org/wiki/Unicode_Transformation_Format#UTF-16
Da steht es ist das älteste, und nichts von "veraltet". In Windows, Java und PHP6 wird auch UTF-16 verwendet, also kann es so schlecht nicht sein.
Was mich auch interessiert ist, wie ich UTF-16 (vor allem nach dem Normalisieren) wieder nach ISO-8859-* bekomme, aber in ein paar Tagen hab ich den entsprechenden Hinweis sicher auf unicode.org gefunden
-
Da steht aber auch, dass es die anderen Formate einschränkt. UTF-8 tut das nicht, es hat viel Spielraum nach oben, ist speichersparender als UTF-16 und außerdem direkt ASCII kompatibel.
Windows, Java und PHP würde ich jetzt nicht unbedingt als die großartigsten Softwarewerke bezeichnen ...Für das Umwandeln wirst du iirc für Zeichen oberhalb des ASCII-Satzes wohl oder übel Tabellen benutzen müssen.
-
.filmor schrieb:
Da steht aber auch, dass es die anderen Formate einschränkt. UTF-8 tut das nicht, es hat viel Spielraum nach oben, ist speichersparender als UTF-16 und außerdem direkt ASCII kompatibel.
UTF-8 wird sich aber (genau deswegen) nicht mehr ändern.
.filmor schrieb:
Windows, Java und PHP würde ich jetzt nicht unbedingt als die großartigsten Softwarewerke bezeichnen ...
lol
.filmor schrieb:
Für das Umwandeln wirst du iirc für Zeichen oberhalb des ASCII-Satzes wohl oder übel Tabellen benutzen müssen.
So mache ich es bereits von ISO-8859 nach Unicode. Umgekehrt macht die Normalisierung (die ich noch nicht ganz verstehe) es schwerer. Bei UTF-16 wird z.B. 'äöü' (6 Byte) zu 'a"o"u"' (12 Byte), wodurch ich nicht einfach eine Tabelle nutzen kann.
Kann aber auch sein, dass ich einfach noch nicht genau verstehe, wozu die Normalisierung gut ist - muss da noch was Forschungsarbeit leisten
-
Hi!
@.filmor:
Nein, das ist nicht der Grund. std::string hat aber keinen virtuellen Destruktor, was eine sehr schlechte Vorraussetzung ist für eine Basisklasse!
@Neku:
Da die STL ein ganz essentieller bestandteil von C++ ist, sollte sie auch verwendet werden. Und nicht veraltete C Funktionen.
Sowiso sehe ich die Abwärtskompatibilität von C++ zu C eher als Nachteil an.grüße
-
Ich verwende ja auch kaum C-Funktionen - wie schon geschrieben ist strlen eine vorübergehende Lösung bis ich eine eigene Funktion geschrieben habe.
-
Neku schrieb:
std::string verwende ich nicht, da ich an einer eigenen Klasse arbeite (wofür ich u.a. das strlen verwende).
Wenn du schon eine eigene String Klasse machst, dann wirf C-Strings komplett über Bord. Die haben nur Nachteile. Für deine Zeichensequenz benutzt du ganz gewöhnliche Arrays. Und statt der str... Funktionen die mem... Funktionen. Und falls du doch mal einen C-String brauchst (zB für WinAPI Funktionen), dann biete eine c_string() Funktion an (so wie das auch std::string macht).
Neku schrieb:
Weiß zufällig jemand, welches Format wchar_t verwendet? UTF-16?
wchar_t "verwendet" überhaupt kein Format. Das ist einfach ein integraler Typ mit einer gewissen Anzahl an Bits. Wieviel das sind, ist plattformabhängig. Es wird lediglich garantiert, dass wchar_t so gross wie char ist und einem der anderen integralen Typen (wie zB short oder int) entsprechen muss.
David_pb schrieb:
Das funktioniert aber auch nur bei statischen Stringwerten.
Welches Wort in "String Literal" hast du denn nicht verstanden?
David_pb schrieb:
std::string wiederrum cached die Länge des Strings und kann somit u.U. schnellere Ergebnisse bringen.
Nein, das tut es in diesem Fall nicht. Und warum das so ist, habe ich ja bereits erläutert.
David_pb schrieb:
Was hast du gegen die STL. Die Klassen sind grandios
Naja, grandios ist doch leicht übertrieben. Es gibt schon einige Mankos, die auch hinreichend diskutiert wurden.
David_pb schrieb:
std::string hat aber keinen virtuellen Destruktor, was eine sehr schlechte Vorraussetzung ist für eine Basisklasse!
Aber nicht, wenn non-public vererbt wird.
-
groovemaster schrieb:
Neku schrieb:
std::string verwende ich nicht, da ich an einer eigenen Klasse arbeite (wofür ich u.a. das strlen verwende).
Wenn du schon eine eigene String Klasse machst, dann wirf C-Strings komplett über Bord. Die haben nur Nachteile. Für deine Zeichensequenz benutzt du ganz gewöhnliche Arrays. Und statt der str... Funktionen die mem... Funktionen. Und falls du doch mal einen C-String brauchst (zB für WinAPI Funktionen), dann biete eine c_string() Funktion an (so wie das auch std::string macht).
Intern habe ich auch keinen C-String mehr - mir geht es nur um die Zuweisung eines C-Strings an meine Klasse, welcher dann automatisch in einem 2-Byte-String gespeichert wird. Bin mir noch gar nicht sicher, ob ich generell für alle Codierungen (ASCII, ISO-8859, Unicode) 2-Byte-Strings verwenden soll. Kommt drauf an, ob ich auch noch UTF-32 erlauben will.
Soll ich, wenn ich eine Stringklasse mit Unicode-Support erstelle nur UTF-16 verwenden oder sämtliche Möglichkeiten erlauben? (UTF-(8/16/32)(LE/BE))