Strings: Ketten sprengen

Oder: Warum Strings immer so besonders sind.

Während sich viele Programmiersprachen klar darüber sind, was Texte oder sogenannte Zeichenketten (Strings) sind, erleben wir in C und C++ einen Religionskrieg, der kulturelle und philosophische Grenzen überschreitet.

In Java oder C# heißt es einfach

String textVar = "Hello World";

Ich hatte anfangs nie verstanden, warum jeder C oder C++ Compiler, jede f~~king UI Bibliothek seine eigene String-Bibliothek etabliert.

Heute mache ich es auch so. … doch WARUM?

Das gute alte char-Array ist nur eine Folge von Bytes. Man kann es nur mit ASCII Zeichen füllen … alles andere sind Erweiterungen oder Non-Standards. (OK, lassen wir die aller neuesten Neuerungen so ab 2013 mal weg).

Noch schlimmer sieht es mit dem wchar_t aus, unter Windows ein 16-Bit String, der als UTF16-LE behandelt wird und unter Linux (… ähm … welches?) meist irgend ein UTF32.

Microsoft war in den späten 80ern/Anfang der 90er mit UTF16 vorgeprescht als Windows NT etabliert wurde. Aber DOS und Windows 9x verharrten darauf, das 8-bit Strings von der Codepage und der Systemsprache abhängig war.

Linux hat - so mein Eindruck - das Thema anfangs verschlafen und dann später still und heimlich behauptet, alle Byte-Strings seien UTF-8 und damit zukunftssicher.

Und von den Großrechnern hört man, dass es noch zahlreiche andere Kodierung von Zeichensätzen gab.

Unsere deutschen Umlaufe zum Beispiel sehen binär auf jeder Plattform anders aus, weshalb C und C++ dieses heiße Eisen nicht anfassen wollten und es dem Entwickler übrig blieb, den Bits einen Sinn zu geben.

Tja, und das tat jeder Entwickler auf seine ganz eigene Art und so haben wir neben char* und std::string auch einen: QString, gchar*, LPTSTR, wxString, CString.

Neben der Bitbreite und der Zeichenkodierung ergibt sich auch noch die Frage, ob ein “String” unveränderlich (immutable) ist oder sich ändern kann, ob er manuell freigegeben werden muss oder garbage-collected / reference-counted ist.

Natürlich wäre es schön, wenn es einen Standard gäbe, der alle glücklich macht, doch in der Tat hat jede dieser Design-Entscheidungen in Fremdprojekten dann auch negative Eigenschaften.

Fazit

Ja, es bleibt für Spezialanwendungen weiter erforderlich, Strings individuell zu verwalten und in andere Formate zu konvertieren. Doch wenn immer es möglich ist, sollte man auf aktuelle Standard-Bibliotheken zurückgreifen.

Viele Bibliotheken, die vor über 15 Jahren entstanden entschieden sich vor allem deshalb für eine eigene Implementierung, da der damals aktuelle Sprachstandard noch nicht ausreichend festgelegt war.

Der neue C und C++ Standard unterstützt UTF-8 und ich persönlich kann nur empfehlen Strings immer als UTF-8 zu speichern und nur an einem Übergangspunkt (z.B. zur WINAPI) in das benötigte Format hin- und her zu konvertieren.

Nachtrag

TurboPASCAL hatte auch sprach-internen String-Support. Doch mit einem 255-Zeichen-Limit war er einfach zu klein und schon damals tummelten sich unzählige (teil Assembler-)Units, die “bessere” Strings nachrüsten sollten.