C-Strings

[schiese]

Hallo,

ich gucke mir gerade die Strings in C++ an und habe da etwas über den C-String gelesen. Ein einfacher String (ein von Anführungszeichen begrenztes Literal) der Form

"Text";

ist vom Typ const char*, also ein Zeiger auf konstante Zeichen.
Wenn ich jetzt etwas wie

const char* text = "Text";

habe, zeigt der Zeiger auf die erste Stelle im Speicher, an der die Zeichenfolge beginnt. Der Ausdruck

std::cout << &text << "\n";

gibt mir auch wie erwartet eine Speicheradresse zurück.
Wenn ich den Zeiger allerdings weiterschalte

while (*text) {
        std::cout << &text << "\n";
        text++;
}

erhalte ich viermal die gleiche Speicheradresse zurück und nicht vier verschiedene, wie ich erwartet habe.

Wieso gibt der weitergeschaltete Zeiger immer noch die Speicheradresse des Stringsanfangs zurück, aber den Buchstaben der jeweiligen Position aus?

Viele Grüße
schiese

 

[Technipion]

Hallo schiese,
ich glaube du hast da einen kleinen Denkfehler drin.

Der Ausdruck

std::cout << &text << "\n";

gibt mir auch wie erwartet eine Speicheradresse zurück.

text ist der Zeiger. Der Ausdruck &text hingegen, zeigt auf deinen Zeiger.

Gruß Technipion

 

[schiese]

Hallo Technipion,

danke für deine Antwort.
Die Ausgabe von

&text

ist die Speicheradresse des Zeigers. Ich habe es jetzt mit printf gelöst um die Speicheradressen der einzelnen Zeichen des Strings zu erhalten

while (*text) {
        printf("Speicheradresse: %p\n", text);
        text++;
}

Ich habe gelesen, dass die einzelnen Zeichen eines Strings (inklusive des Null-Characters) im Arbeitsspeicher nacheinander abgespeichert werden. Das bekomme ich auch raus. Ist das immer so?

Gruß schiese

 

[cwriter]

Ich habe es jetzt mit printf gelöst um die Speicheradressen der einzelnen Zeichen des Strings zu erhalten

Nicht nötig, das geht auch mit C++:

while(*text) {
    std::cout << "Speicheradresse: " << reinterpret_cast<const void*>(text) << std::endl;
    text++;
}

In C++ nimmt der operator<< einfach den Typ "char*" als String und nicht als Pointer, daher wird dann der (Sub)string und nicht die Adresse ausgegeben.

Ich habe gelesen, dass die einzelnen Zeichen eines Strings (inklusive des Null-Characters) im Arbeitsspeicher nacheinander abgespeichert werden. Das bekomme ich auch raus. Ist das immer so?

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

In translation phase 6, the multibyte character sequences specified by any sequence of adjacent character and wide string literal tokens are concatenated into a single multibyte character sequence. If any of the tokens are wide string literal tokens, the resulting multibyte character sequence is treated as a wide string literal; otherwise, it is treated as a character string literal. 5 In translation phase 7, a byte or code of value zero is appended to each multibyte character sequence that results from a string literal or literals. The multibyte character sequence is then used to initialize an array of static storage duration and length just sufficient to contain the sequence. For character string literals, the array elements have type char, and are initialized with the individual bytes of the multibyte character sequence; for wide string literals, the array elements have type wchar_t, and are initialized with the sequence of wide characters corresponding to the multibyte character

(Seite 62)
Und der Array:

An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type

(Seite 35)

Also: Ja, der String Literal wird in einen Array kopiert (oder ist als solcher lesbar) und ein Array hat keine Lücken zwischen den Zeichen. Aber:
Es gibt wchar_t bzw. andere Speicherarten (Unicode bzw. als Speicherformat UTF-8/UTF-16/...).
D.h. z.B., dass wenn du ein L vor deinen Literal stellst, also

auto x = L"Hallo";
//decltype(x) == "const wchar_t*"

Wenn du dann auf "const char*" castest und dann iterierst, würdest du zwischen den einzelnen Zeichen 0-Werte haben. (wchar_t ist meistens 16bit).
Übrigens ein weiterer Grund, warum Casts in C++ sehr ungern gesehen werden. Daher auch der reinterpret_cast im Beispiel oben: Der erlaubt fast alles; es ist dann aber auch dein Problem, wenn nichts geht. Die C-style-casts sind sehr freigiebiger. In C++ nutzt man stattdessen Operator Overloading, um nicht-passende Typen passend zu machen. In C ging das nicht, deshalb sind dort Casts verbreiteter (was nicht passt, wird passend gemacht - man sieht die Probleme halt später).


Gruss
cwriter

 

[Technipion]

Ich schließe mich cwriter gänzlich an.

Und gerade falls dich die Ausrichtung im Speicher interessiert @schiese , schau dir doch mal das hier an:
Objects and alignment - cppreference.com

Insbesondere das Thema "Alignment". Ist ganz interessant...

Gruß Technipion

 

[ComFreek]

Es gibt wchar_t bzw. andere Speicherarten (Unicode bzw. als Speicherformat UTF-8/UTF-16/...).

Insbesondere sollte man sich früh von der Vorstellung lösen, dass "ein Zeichen == char" oder "ein Zeichen == 8 Bit" o. Ä.
Oder dass zwei Strings nur dann gleich sind, wenn ihre Bitinhalte gleich sind. Stichwort Unicode Normalization. Es gibt in Unicode z. B. verschiedene ein "ä" darzustellen. Einmal als "ä" selbst und ein anderes Mal als "a" + "zwei Punkte oben".
Man sollte auch immer besser nachdenken, bevor man über einen String Zeichen-für-Zeichen mit for iteriert. Das geht sehr schnell kaputt, wenn du nicht gerade nur ASCII erlaubst.

 

[cwriter]

Insbesondere sollte man sich früh von der Vorstellung lösen, dass "ein Zeichen == char" oder "ein Zeichen == 8 Bit" o. Ä.

Alles völlig korrekt, allerdings muss man hier relativieren:
Gerätetreiber (bzw. Identifierstrings/Commandstrings darin), einfache Programme (für den Eigengebrauch), Microcontroller bzw. alles, was in ASCII sinnvoll machbar ist, sollte man in ASCII machen, wenn man in C/C++ programmiert. Mit etwas Phantasie auch in Wide Strings (vor allen Windows mit UCS-2), man verschenkt aber schon grosszügig Performance/Speicher.
Für alles, was ein Nutzer sehen soll: Unicode-Library verwenden. UTF-8 ist vor allem im Web sehr beliebt, und ich würde auch zu diesem Format raten: Standard-ASCII-Kompatibel (nicht extended ASCII), und man zahlt (fast) nur für spezielle Zeichen ausserhalb von ASCII mehr.

Gruss
cwriter