Na ja ... Irgendwie schon. Am einfachsten ist es, einfach die Tatsache zu nutzen, dass benachbarte String-Literale vom Compiler verkettet werden:
const char *text =
"This text is pretty long, but will be "
"concatenated into just a single string. "
"The disadvantage is that you have to quote "
"each part, and newlines must be literal as "
"usual.";
Die Einrückung spielt keine Rolle, da sie nicht innerhalb der Anführungszeichen steht.
Sie können dies auch tun, solange Sie darauf achten, den eingebetteten Zeilenumbruch zu vermeiden. Wenn Sie dies nicht tun, wie es in meiner ersten Antwort der Fall war, wird der Text nicht kompiliert:
const char \*text2 =
"Here, on the other hand, I've gone crazy \\
and really let the literal span several lines, \\
without bothering with quoting each line's \\
content. This works, but you can't indent.";
Beachten Sie auch hier die Backslashes am Ende jeder Zeile. Sie müssen unmittelbar vor dem Zeilenende stehen, da sie den Zeilenumbruch im Quelltext umgehen, so dass sich alles so verhält, als ob der Zeilenumbruch nicht vorhanden wäre. Sie erhalten keine Zeilenumbrüche in der Zeichenkette an den Stellen, an denen Sie Backslashes hatten. Bei dieser Form können Sie den Text natürlich nicht einrücken, da die Einrückung dann Teil der Zeichenkette wird und diese mit zufälligen Leerzeichen durcheinander bringt.
2 Stimmen
Im Allgemeinen sollten Sie keine Stringliterale in den Code einbetten. Für I18N und L10N ist es besser, String-Literale in eine Konfigurationsdatei zu schreiben, die zur Laufzeit geladen wird.
63 Stimmen
Es gibt genügend Fälle, in denen das Einfügen von String-Literalen in den Code kein Problem darstellt: wenn der String nicht verwendet wird, um ihn dem Benutzer darzustellen; d.h.: SQL-Anweisungen, Dateinamen, Namen von Registrierungsschlüsseln, auszuführende Befehlszeilen, ...
4 Stimmen
@Martin: Es kann aber trotzdem nützlich sein, das zu wissen. Ich habe es zum Beispiel gemacht, um komplexe Regexe aufzulösen.