[Strings] Welche benutzt ihr?

Konrad Rudolph

ok, Frage: wieso verwendet ihr "string", nicht "wstring"? Zu langsam? Andere Gründe?

otze

string is für char
wstring für wchar_t

CarstenJ

So komplex find ich std::string nicht, als dass man dafür nen Tutorial bräuchte. Imho reichte eine Referenz, in der einige Beispiel vorhanden sind:

www.cppreference.com
http://www.dinkumware.com/htm_cpl/string2.html

Eins hab ich dann doch gefunden:
http://www.yolinux.com/TUTORIALS/LinuxTutorialC++StringClass.html

Mis2com

Hallo,

Char Arrays benutzt man in C, in C++ würde ich immer strings vorziehen, es sei denn, eine bestimmte Funktion erwartet ein char*.

Auch hier sind char-Arrays nur bedingt vorzuziehen, da man, bevor man den Parameter übergibt, mit string oft viel konfortabler arbeiten kann. Für die Übergabe als (const) char* gibt es dann strings schöne Methode c_str().

Ich bevorzuge meine eigene String-Klasse. Die ist vielleicht nicht so schnell und bugfrei wie std::String, aber man kennt alle Befehle , man kann lernen vernünftige Interfaces zu schreiben und übt sich fast zwangsweise in Operatoren-Überladung.

Einmal schreiben zur Übung ist ok, danach wird man aber an der Klasse nichts mehr großartig ändern, daher ist der Übungsfaktor auf Dauer = 0.
Einmal String-Klasse zur Übung schreiben
Danach std::string für Projekte verwenden

MfG Eisflamme

Artchi

otze schrieb:

ich bin ein benutzer von char arrays und strings.
ich bin der meinung, dass strings in vielen Fällen einfach nur wie mit nem Raketenwerfer auf Spatzen schießen ist.
ich meine, wenn ich nur 10 zeichen text brauche,um irgendeine datei zu öffnen und zu kopieren, dann fahr ich nicht std::strings auf,das ist einfach nur umständlich.
Für alles andere, insbesondere wenn ich dynamisch text erstelle, benutz ich natürlich std::string.

Sorry, dann hast du aber das OO-Konzept nicht verstanden. Was soll bitte an string "übertrieben" sein?

Wenn du z.B.

std::string str("hallo");

schreibst, was meinst du passiert da im Hintergrund? Da passiert nicht mehr, als das im Speicher 5 Bytes reserviert werden, und ein integer, der sich die Länge der Zeichenkette merkt. Mehr passiet da im Speicher ÜBERHAUPT nicht. Es ist nicht mehr Speicherverbrauch, als wenn du:

char str[6] = "hallo";

schriebst.

string ist nicht mit Kanonen auf Spatzen geschossen, es ist nur eine andere Denkweise. Anstatt das ich mit 10 C-String-Funktionen (umständlich) arbeite, ist das einfach nur in String-Methoden gekapselt.

otze

string benutzt new, das nur mal so am rande erwähnt

Um es mal nüchtern zu betrachten, ist ein std::string nichts anderes als ein char-Array. Und anstatt man mit Funktionen von außen darauf zugreift, sind die Funktionen in der Klasse drin.

Ich benutze praktisch nur wstring in Verbindung mit boost::lexical_cast.

Konrad Rudolph

otze schrieb:

string is für char
wstring für wchar_t

Yo, das ist mir klar. Ich formuliere meine Frage um: wieso verwenden hier anscheinend alle ANSI-Strings, wenn sie stattdessen Unicode-Strings verwenden könnten und somit Programme schreiben, die modernere Standards konformieren? (kommt natürlich immer auf den Verwendungszweck an, schon klar!)

Artchi

otze schrieb:

string benutzt new, das nur mal so am rande erwähnt

??? Was willst du mir damit sagen? Ob ich das String-Objekt im Heap oder Stack anlege, ändert nichts an den Fakten.

otze

mal fix aus der bcb hilfe:

A wchar_t type is the same size, signedness, and alignment requirement as an int type.

damit ist ein wchar_t so groß wie 32 normale chars

@Artchi
char* text=new char[6];
*text="Hallo";
ist langsamer als
char[6]=Hallo;
deshalb benutz ich gerne char arrays für Kleinigkeiten.

und performance ändert wohl was an den fakten!

Konrad Rudolph

otze schrieb:

string is für char
wstring für wchar_t

Das ist mir klar. Ich formuliere meine Frage um: wieso verwenden hier (scheinbar) alle ANSI-Strings, wenn sie stattdessen Unicode-Strings verwenden könnten? Man beachte: Unicode ist ein neuerer und weitaus umfassenderer Standard.

(Kommt natürlich auf den genauen Einsatz an, aber in den meisten (= eigentlich allen) Gebieten sollte man Unicode verwenden.)

EDIT:
Sorry, Doppelposting. Bitte löschen.

Konrad Rudolph

otze schrieb:

mal fix aus der bcb hilfe:

A wchar_t type is the same size, signedness, and alignment requirement as an int type.

damit ist ein wchar_t so groß wie 32 normale chars

Hmm, also ich komme auf viermal: ein char ist 8 Bit, nicht ein Bit! Außerdem sollte es bei modernen PCs kein Problem mehr sein, viermal größere Strings zu bearbeiten. Ob man nun mit 8 Bit oder mit 32 Bit rechnet, ist einem 32-Bit-Prozessor sowieso egal (er paddet die 8 Bit auf 32 hoch). D.h. die Geschwindigkeit sollte die gleiche sein, nur der Speicherbedarf (im RAM!) ist höher.

Artchi

Naja, weil Unicode leider nicht so gut unterstützt wird, wie man meinen sollte.

Wir benutzen in unseren Projekten (im VW-Konzern) nur auf Anforderung Unicode in den Java-Applikationen. Bis vor gut 12 Monaten war es unmöglich Unicode auf einer IBM DB2-Datenbank auf einem IBM-Mainframe OS/390 (ja, kein popliger Intel-Server!) abzulegen. Es kam am Ende nur Datenschrott bei raus. Selbst das Euro-Zeichen macht uns heute noch sorgen, wenn wir diese in der DB2 speichern wollen. Und das, obwohl so ein Mainframe ein paar Mio. Euro kostet, funktionierte nicht mal das bis vor gut einem Jahr.

Man kann/muß nicht immer allem neuen hinterher laufen.

Und das Unicode-Problem ist uns auf dem Mainframe nur aufgefallen, weil die Applikation auch bei VW-China eingesetzt werden sollte. Bisher haben wir nur ANSI-Code benutzt, was ausreichend war.

otze

Konrad Rudolph schrieb:

otze schrieb:

mal fix aus der bcb hilfe:

A wchar_t type is the same size, signedness, and alignment requirement as an int type.

damit ist ein wchar_t so groß wie 32 normale chars

Hmm, also ich komme auf viermal: ein char ist 8 Bit, nicht ein Bit! Außerdem sollte es bei modernen PCs kein Problem mehr sein, viermal größere Strings zu bearbeiten. Ob man nun mit 8 Bit oder mit 32 Bit rechnet, ist einem 32-Bit-Prozessor sowieso egal (er paddet die 8 Bit auf 32 hoch). D.h. die Geschwindigkeit sollte die gleiche sein, nur der Speicherbedarf (im RAM!) ist höher.

ja bei der größe muss ich dir zustimmen, mein fehler, hab bit/Byte vertauscht^^
aber ramspeicher ist immer sehr rar,vorallem bei größeren Programmen, da man sogar heute noch keine 512mb ram in nem pc als standard bezeichnen kann,macht sich der doch viel höhere speicherbedarf bei Unicode sehr stark bemerkbar.

Unsinn, das macht sich kein Stück bemerkbar. Zur Info, der am häufigsten verwendete Unicode-Standard braucht 2Byte pro Zeichen und umfasst alle europäischen und die meisten (wichtigsten) asiatischen Sprachen.
Wenn du ein Bitmap in Bildschirmgröße malst, kannst du damit genauso viel Speicher verbraten wie mindestens 1000 Zeichen Text. Ist doch ein völliger Unsinn, an der falschen Stelle rumzugeizen.
Ein paar Textdaten sind i.d.R. nicht das, was den ganzen RAM zusammenfrisst, sondern eher ein paar 100MB an Leveldaten und Texturen in Far Cry.

Konrad Rudolph

Optimizer schrieb:

Unsinn, das macht sich kein Stück bemerkbar. Zur Info, der am häufigsten verwendete Unicode-Standard braucht 2Byte pro Zeichen und umfasst alle europäischen und die meisten (wichtigsten) asiatischen Sprachen.

Ich nehme mal an Du sprichst von MS's Pseudo-UTF-16 (wird in vielen WinAPIs verwendet, sowie in VBC und .NET)? Tja, das ist leider etwas proprietäres von MS und daher ganz schlecht, wenn man plattformübergreifend programmieren möchte ... Aber nun ja, zur Not macht man sich das selber.

otze

Optimizer schrieb:

Unsinn, das macht sich kein Stück bemerkbar. Zur Info, der am häufigsten verwendete Unicode-Standard braucht 2Byte pro Zeichen und umfasst alle europäischen und die meisten (wichtigsten) asiatischen Sprachen.
Wenn du ein Bitmap in Bildschirmgröße malst, kannst du damit genauso viel Speicher verbraten wie mindestens 1000 Zeichen Text. Ist doch ein völliger Unsinn, an der falschen Stelle rumzugeizen.
Ein paar Textdaten sind i.d.R. nicht das, was den ganzen RAM zusammenfrisst, sondern eher ein paar 100MB an Leveldaten und Texturen in Far Cry.

wir reden hier von wchar_t das sind 4 byte,also nur 500 zeichen,und nehmen wir ein komplettes Buch im Unicode format haben wir sofort verschissen

sizeof(wchar_t) ist bei mir 2. Das ist natürlich Implementierungsabhängig, aber wie gesagt, UCS-2 ist der geläufigste Standard.

rüdiger

otze schrieb:

string benutzt new, das nur mal so am rande erwähnt

nö, string nutzt einen Allocator, der muss nicht new verwenden oder gar den Heap

zu dem was du zu Unicode sagst, kann ich nur sagen, dass du absoluten blödsinn erzählst. Bei heutigen PCs kommt es nicht auf 1MB mehr oder weniger an. Schau dir mal eine Anwendung an, die viel RAM verbraucht. Dafür geht so gut wie nichts für Text drauf. Auch wenn du ein oder mehrere Buch komplett in Unicode hast, ist das kein Problem.

Konrad Rudolph schrieb:

Ich nehme mal an Du sprichst von MS's Pseudo-UTF-16 (wird in vielen WinAPIs verwendet, sowie in VBC und .NET)? Tja, das ist leider etwas proprietäres von MS und daher ganz schlecht, wenn man plattformübergreifend programmieren möchte ... Aber nun ja, zur Not macht man sich das selber.

nein, dass ist nichts proprietäres, sondern einfach UCS-2. Ist zwar mittlerweile veraltet, deswegen gibt es UTF-16 um veraltete Architekturen (wie zB. Windows XP) mit dem kompletten Unicode Zeichensatz bedienen zu können.

@Optimizer
warum der geläufigste Standard?

@Artchi
UTF-8

@Optimizer
warum der geläufigste Standard?

Ok, war vielleicht vorschnell geurteilt.
Auf jeden Fall implementieren alle mir bekannten C++ Implementierungen (ok, sind nicht so viele ), Java und C# diesen Standard. Deshalb bin ich jetzt einfach mal davon ausgegangen. Wir reden ja auch nur über Programmiersprachen, oder?