Wo sind die Funktionen für Strings?
-
In C++ gibt es die aus C bekannten Routinen für POD-Strings (char*) wie strlen(), strcpy(), strchr(), strcmp() in <cstring>.
Das Stringobjekt std::basic_string<> oder auch seine Spezialisierung auf Characters std::string kommen aus <string> und finden sich im namespace std, wie alles aus der STL. Als Objekte wissen Strings in C++ am besten selbst, was man mit ihnen machen kann und bringen dementsprechende Methoden mit.
-
@kenner der dummköpfe
Also irgendwie hört sich das ja schön an was du schreibst, aber ich versteh das irgendwie nicht, und somit bleiben meine Fragen leider offen.
Wie würdest du den z.B. das Problem mit dem string (aus meinem letzten Posting)
und der Großbuchstaben schreibung lösen?
Dankeschön schon mal im Voraus.
-
-
@Stromberg: Die Funktionen für Strings sind hier:
http://www.oop-mit-cpp.de/stdbib_html/p133.html
So etwas wie toupper/tolower ist nicht dabei, aber es geht mit transform, wie schon im Link von bens angedeutet. ZB. Umwandlung in Kleinbuchstaben:string s("ABC123"); transform(s.begin(), s.end(), s.begin(), tolower);
-
Die meisten Funktionen für Strings sind linksoben.
-
UBr schrieb:
string s("ABC123"); transform(s.begin(), s.end(), s.begin(), tolower);entfern lieber den code, denn er ist nicht portabel. wirft ein schlechtes bild auf dein buch.
-
gesucht war
etwas für Strings, wie <cstring> bei C-Strings.
Umlaute werden natürlich nicht berücksichtigt usw., d.h. der Code ist genauso so portabel bzw. unportabel wie <cstring> eben ist.
-
UBr schrieb:
gesucht war
etwas für Strings, wie <cstring> bei C-Strings.
Umlaute werden natürlich nicht berücksichtigt usw., d.h. der Code ist genauso so portabel bzw. unportabel wie <cstring> eben ist.
Stimmt so nicht. Die Funktionsweise hängt von dem globalen Locale ab.
-
-
lolz schrieb:
UBr schrieb:
gesucht war
etwas für Strings, wie <cstring> bei C-Strings.
Umlaute werden natürlich nicht berücksichtigt usw., d.h. der Code ist genauso so portabel bzw. unportabel wie <cstring> eben ist.
Stimmt so nicht. Die Funktionsweise hängt von dem globalen Locale ab.
und auch von dem vom Compiler verwendeten Zeichensatz.
-
@otze: Die Funktionsweise hat mit dem "Zeichensatz des Compilers" (-> Zeichensatz in dem er Source Files interpretiert) garnix zu tun, sondern wie schon geschrieben wurde mit der globalen locale.
Wenn man was sucht worauf man sich verlassen kann und was wirklich portabel ist muss man wohl auf eine externe Unicode lib zurückgreifen, ala ICU. (OK, ICU ist ein schlechtes Beispiel weil voll mit Bugs, wird aber dennoch sehr häufig verwendet.)
-
hustbaer schrieb:
@otze: Die Funktionsweise hat mit dem "Zeichensatz des Compilers" (-> Zeichensatz in dem er Source Files interpretiert) garnix zu tun, sondern wie schon geschrieben wurde mit der globalen locale.
wenn der compiler keine umlaute in string literalen in seinem grundzeichensatz kennt, ist das nicht möglich,diese literale korrekt umzuwandeln. Locale hin oder her, du kriegst immer ein falsches Ergebnis.
2.13.2.5
A universal-character-name is translated to the encoding, in the execution character set, of the character named. If there is no such encoding, the universal-character-name is translated to an implementationdefined encoding.
[Note: in translation phase 1, a universal-character-name is introduced whenever an actual extended character is encountered in the source text. Therefore, all extended characters are described in terms of universal-character-names. However, the actual compiler implementation may use its own native character set, so long as the same results are obtained. ]
-
Deshalb sollte man, um ganz Sicher zu gehen, Sonderzeichen immer mit dem Unicode-Escapezeichen eingeben:
string s(L"\u0041"); // Unicode-Zeichen #41Sobald jemand die cpp-Datei in einem nicht Unicode-Editor öffnet und abspeichert, ist alles dahin. Mit den \u-Escape kann das nicht passieren.
-
Richtig. Java hat wegen dieses Problems konsequent auf Unicode gesetzt. Im nächsten C++-Standard soll C++ als Ergänzung zu wchar_t deshalb zwei weitere Datentypen erhalten, char16_t und char 32_t (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2149.html). Im Standardentwurf vom 7.5.2007 sind diese neuen Typen enthalten.
