1. Einführung
Ehrlich gesagt sind Leerzeichen und Anführungszeichen die Hauptstörer beim Parsen. Sie sehen harmlos aus: „na und, ein extra Leerzeichen“. Aber genau daraus entstehen Situationen, in denen dein Code „fast funktioniert“ und plötzlich nicht mehr — weil jemand zwei Leerzeichen eingegeben hat, ein leeres Feld zwischen Kommas oder einen Namen aus zwei Wörtern.
In dieser Vorlesung wollen wir keinen „perfekten universellen Parser“ erfinden, sondern typische Formatprobleme früh erkennen und einfache Tricks anwenden, damit die Anwendung zumindest zuverlässig entscheiden kann: ist das Format gültig oder nicht.
Die Beispiele bauen auf einer Mini‑Applikation auf: einer Konsolen‑ToDo‑Liste. Wir speichern Aufgaben in std::vector<std::string> und lesen Befehle zeilenweise mit std::getline(std::cin, line).
2. Mini‑Skeleton CLI ToDo
Um konkret zu sein, brauchen wir einen Ausgangspunkt: eine Schleife, die Zeilen liest, und eine primitive Kommando‑Analyse. Hier starten wir bewusst mit einer „naiven“ Version — und finden dann, wo genau sie bei Leerzeichen/Anführungszeichen/leeren Feldern versagt.
#include <iostream>
#include <ssstream>
#include <string>
#include <vector>
int main() {
std::vector<std::string> tasks;
std::string line;
while (std::getline(std::cin, line)) {
std::istringstream iss(line);
std::string cmd;
iss >> cmd;
if (cmd == "add") {
std::string text;
std::getline(iss, text); // vorerst "wie es ist"
tasks.push_back(text);
std::cout << "added\n"; // added
} else if (cmd == "list") {
for (std::size_t i = 0; i < tasks.size(); ++i) {
std::cout << (i + 1) << ") " << tasks[i] << '\n';
}
} else if (!cmd.empty()) {
std::cout << "unknown command\n"; // unknown command
}
}
}
Auf diesem Stand scheint alles in Ordnung. Aber zwei zukünftige Probleme sind bereits versteckt: getline(iss, text) gibt eine Zeichenfolge zurück, die oft mit einem Leerzeichen beginnt, und der Befehl "add" würde technisch eine Aufgabe hinzufügen, selbst wenn kein Text vorhanden ist (oder dieser nur aus Leerzeichen besteht).
3. Leerzeichen: Trennzeichen und Teil der Daten
Ein Leerzeichen ist gleichzeitig „Token‑Trennzeichen“ und ein normales Zeichen, das Teil eines Werts sein kann. Und hier beginnt die Philosophie des Formats: in einem Format sind Leerzeichen unwichtig (zwischen Zahlen), in einem anderen sind sie kritisch (im Aufgabentitel).
Wir betrachten drei typische Situationen: überflüssige Leerzeichen um Tokens, Leerzeichen als Teil eines Werts, und der tückische Fall — die Mischung aus operator>> und getline, wenn am Anfang des Reststrings ein „Leerschwanz“ auftaucht.
Überflüssige Leerzeichen: operator>> schluckt sie, getline speichert sie
Wenn du iss mit >> in cmd liest, überspringpt der Stream‑Operator operator>> links liegende Leerzeichen und Tabs. Das ist praktisch: der Befehl " list" wird trotzdem als "list" erkannt. Aber getline funktioniert anders: es liest alles „wie es ist“ bis zum Zeilenende, inklusive führender Leerzeichen.
Schauen wir uns den Effekt an einem Beispiel an:
#include <iostream>
#include <ssstream>
#include <string>
int main() {
std::string line = "add Buy milk";
std::istringstream iss(line);
std::string cmd;
iss >> cmd;
std::string rest;
std::getline(iss, rest);
std::cout << "cmd=[" << cmd << "]\n"; // cmd=[add]
std::cout << "rest=[" << rest << "]\n"; // rest=[ Buy milk]
}
rest beginnt mit einem Leerzeichen, weil nach dem Lesen von cmd der Stream vor dem ersten Leerzeichen stehen geblieben ist und getline ehrlich den „Rest der Zeile“ inklusive dieses Leerzeichens liest.
Das ist kein „C++‑Fehler“, das ist die normale Logik: du musst entscheiden, ob dieses Leerzeichen Teil des Formats oder unerwünschter Müll ist.
Mini‑Trim: führende Leerzeichen des „Reststrings“ entfernen
Wir machen eine kleine Funktion, die Leerzeichen und Tabs links entfernt. Ja, das ist nicht der schnellste Trim der Welt (wir verwenden erase(0, 1) in einer Schleife), aber für ein Lehr‑Konsolenprogramm ist das ausreichend.
#include <string>
void ltrimSpaces(std::string& s) {
while (!s.empty() && (s[0] == ' ' || s[0] == '\t')) {
s.erase(0, 1);
}
}
Und wir wenden es in "add" an:
if (cmd == "add") {
std::string text;
std::getline(iss, text);
ltrimSpaces(text);
tasks.push_back(text);
std::cout << "added: " << text << '\n';
}
Jetzt wird "add Buy milk" die Aufgabe "Buy milk" speichern und nicht " Buy milk".
Aber hier taucht eine neue Formatfrage auf: darf man eine leere Aufgabe hinzufügen? Was ist mit "add" ohne Text? Was ist mit "add "?
„Leer“ vs. Leerzeichen: warum die Unterscheidung wichtig ist
Aus Sicht des Benutzers bedeutet der Befehl "add" ohne Text meistens „ich habe mich vertippt“, nicht „füge eine leere Zeile hinzu“. Der Computer hingegen fügt leicht eine leere Zeile hinzu und ist zufrieden, wie ein Compiler, der etwas zum Kritisieren gefunden hat.
Wir fügen eine Prüfung hinzu: nach dem Trim gilt eine leere Zeichenfolge als ungültiges Format.
if (cmd == "add") {
std::string text;
std::getline(iss, text);
ltrimSpaces(text);
if (text.empty()) {
std::cout << "usage: add <text>\n"; // usage: add <text>
continue;
}
tasks.push_back(text);
std::cout << "added\n"; // added
}
Das ist guter Stil beim Parsen: nicht zu versuchen, „zu erraten, was der Benutzer gemeint hat“, sondern den Vertrag ehrlich durchzusetzen und abzulehnen, wenn er verletzt wird.
4. Leere Felder: warum "a;;b" drei Felder sind
Leere Felder sind die zweite klassische Falle. Sie treten typischerweise in Formaten wie CSV (durch Kommas getrennte Felder), Logs, Konfigurationen und „Befehlen mit Listen von Werten“ auf. Ein Anfänger denkt oft: „wenn zwischen Kommas nichts ist, dann existiert dieses Feld nicht“. In positionsbasierten Formaten aber existiert ein leeres Feld und bedeutet „Wert ausgelassen“.
Um den Unterschied zu spüren, fügen wir dem ToDo‑Programm den Befehl "bulk_add" hinzu, der mehrere Aufgaben auf einmal hinzufügt, getrennt durch das Zeichen ';':
bulk_add buy milk;wash car;;call mom
Zwei aufeinanderfolgende Semikolons bedeuten eine leere Aufgabe dazwischen. Frage: ignorieren wir die leere Aufgabe oder werten wir das als Fehler? Das ist wieder Teil des Formatvertrags — und wir müssen eine Entscheidung treffen.
Der Separator ist kein Leerzeichen: warum operator>> hier nutzlos ist
Wenn man versucht, solche Werte mit operator>> zu lesen, wird das nicht gut funktionieren: operator>> splittet nach Whitespace, und das ';' ist für ihn einfach Teil des Tokens. Also bleibt "buy milk;wash car" ein Stück, wenn nicht an den „richtigen“ Stellen Leerzeichen vorhanden sind.
Wir brauchen ein Instrument „lies bis zum Separator“. Und genau das ist std::getline(stream, token, delim).
Parsing von "bulk_add" mit getline(..., ';')
Hier ein minimales Feld‑Parsing:
#include <iostream>
#include <ssstream>
#include <string>
int main() {
std::string line = "buy milk;wash car;;call mom";
std::istringstream iss(line);
std::string item;
while (std::getline(iss, item, ';')) {
std::cout << "[" << item << "]\n";
}
}
Die Ausgabe sieht so aus (beachte das leere Element):
[buy milk]
[wash car]
[]
[call mom]
Das heißt: das leere Feld ist nicht „verschwunden“. Das ist sehr nützlich, weil man ehrlich sagen kann: „an Position drei ist leer“.
Vollständig leere Zeile: ein Sonderfall
Tückisch ist: wenn die Eingabezeile komplett leer ist (""), dann wird die Schleife while (getline(...)) kein einziges Mal ausgeführt. Manchmal bedeutet eine leere Zeile laut Vertrag „eine leere Spalte“, manchmal „keine Daten“.
Für unseren Befehl "bulk_add" ist es sinnvoll zu sagen: wenn nach dem Befehl nichts kommt — ist das ein Formatfehler (nichts zum Hinzufügen).
"bulk_add" in die Anwendung einbauen
Handler hinzufügen:
if (cmd == "bulk_add") {
std::string rest;
std::getline(iss, rest);
ltrimSpaces(rest);
if (rest.empty()) {
std::cout << "usage: bulk_add a;b;c\n"; // usage: bulk_add a;b;c
continue;
}
std::istringstream items(rest);
std::string item;
while (std::getline(items, item, ';')) {
ltrimSpaces(item);
if (item.empty()) {
std::cout << "skip empty item\n"; // skip empty item
continue;
}
tasks.push_back(item);
}
std::cout << "bulk added\n"; // bulk added
}
Hier haben wir eine Vertragsentscheidung getroffen: leere Elemente sind kein Fehler, aber wir überspringen sie. Das ist nicht die einzige Möglichkeit, aber sie ist verständlich und vorhersagbar.
5. Anführungszeichen: Werte mit Leerzeichen
Wenn Leerzeichen und leere Felder „technische“ Formatprobleme sind, dann sind Anführungszeichen fast schon „Sprachen‑Design“. Sie treten auf, wenn man den streambasierten Parsing‑Stil beibehalten möchte ("cmd value number"), aber Werte wie "milk chocolate" als ein Token erlauben möchte.
Hier macht ein Anfänger oft Folgendes: liest die Zeile mit operator>> und wundert sich, dass "milk chocolate" in zwei Tokens zerfällt. Das ist logisch: operator>> kann nicht „erraten“, dass ein Leerzeichen innerhalb von Anführungszeichen Teil des Werts sein soll.
Problem‑Demo: operator>> schneidet bei Leerzeichen
Ein praktisches Scheitern:
#include <iostream>
#include <ssstream>
#include <string>
int main() {
std::string line = "add \"milk chocolate\"";
std::istringstream iss(line);
std::string cmd;
std::string text;
iss >> cmd >> text;
std::cout << "cmd=" << cmd << '\n'; // cmd=add
std::cout << "text=" << text << '\n'; // text="milk
}
Wir erhalten text="milk, weil das zweite Token nur bis zum ersten Leerzeichen reicht. Der Rest (chocolate") bleibt im Stream.
Wichtig ist: nicht „die Streams sind schlecht“, sondern der Formatvertrag ist nicht eindeutig. Wenn ein Format Leerzeichen innerhalb eines Felds erlaubt, muss es eine Regel geben, wie man „Trenn‑Leerzeichen“ von „Wert‑Leerzeichen“ unterscheidet. Die gängigste Regel sind Anführungszeichen.
Zwei Ebenen von Anführungszeichen: Daten und C++‑Literal
Im obigen Beispiel war die Zeile so geschrieben: "add \"milk chocolate\"". Das ist nicht, weil das Format so kompliziert ist, sondern weil wir die Daten innerhalb eines C++‑Stringliterals geschrieben haben, und dort ist \" die Art, ein Anführungszeichen zu kodieren.
Also gibt es zwei Ebenen.
Ebene 1 — die Daten, die der Benutzer eingibt:
add "milk chocolate"
Ebene 2 — wie man diese Daten in C++‑Code schreibt:
std::string line = "add \"milk chocolate\"";
Wenn man diese Ebenen durcheinanderbringt, entstehen Mythen wie „der Benutzer muss Slashes vor Anführungszeichen eingeben“. Nein — das muss er nicht. Slashes sind nur für Literale in C++.
Temporäre Lösung ohne Quote‑Support
In dieser Vorlesung verwenden wir noch keinen speziellen Mechanismus, um Anführungszeichen als ein Token zu behandeln. Aber man kann vorläufig eine Formatentscheidung treffen, damit die App praktikabel ist.
Entweder sagen wir: „bei 'add' ist der Text der Rest der Zeile nach dem Befehl“. Dann sind Leerzeichen erlaubt und Anführungszeichen unnötig:
add milk chocolate
Oder wir sagen: „'add' akzeptiert einen Token ohne Leerzeichen“. Dann muss der Benutzer z.B. Unterstriche verwenden:
add milk_chocolate
Die erste Variante ist normalerweise benutzerfreundlicher: in einer Notiz‑CLI möchte man oft Phrasen eingeben.
Und diese Variante haben wir bereits implementiert: "add" liest den Rest der Zeile mit getline.
Wenn du aber ein Format wie dieses haben willst:
add <text> <priority>
wobei <text> Leerzeichen enthalten kann und <priority> eine Zahl ist, dann brauchst du echte Anführungszeichen‑Unterstützung.
Warum Anführungszeichen Teil der Standardbibliothek sind
Die gute Nachricht: die Idee „String in Anführungszeichen als ein Token“ ist so verbreitet, dass es dafür Standardlösungen gibt. Wir machen in der nächsten Vorlesung weiter und betrachten std::quoted ausführlicher.
Spickzettel: wie man typische Probleme behandelt
Wenn man anfängt, Parser zu schreiben, kann man leicht verzweifeln und denken, „Formate sind immer schlimm“. In der Praxis ist alles einfacher: für jede Problemart gibt es typische Mittel. Unten eine kleine Tabelle, damit du schnell Symptom und Gegenmaßnahme abgleichen kannst.
| Format‑Symptom | Beispiel‑Eingabe | Warum es bricht | Typische Maßnahme |
|---|---|---|---|
| Überflüssige Leerzeichen um Daten | |
getline behält die Leerzeichen | Trim des Reststrings (mindestens links) |
| Leerzeichen im Feld | |
wenn per operator>> gelesen, wird das Feld zerschnitten | Rest der Zeile mit getline lesen |
| Felder durch ,/; und leere Werte | |
operator>> trennt nicht nach ;, leere Felder gehen in „naiven Splits“ verloren | getline(stream, token, ';'), bewusstes Handhaben leerer Felder |
| Feld in Anführungszeichen enthält Leerzeichen | |
operator>> versteht keine Anführungszeichen | Format mit Anführungszeichen + std::quoted |
6. Typische Fehler
Fehler Nr.1: zu glauben, dass getline „automatisch Leerzeichen entfernt“.
std::getline „normalisiert“ oder „säubert“ nichts. Es liest die Zeichen ehrlich, wie sie sind. Deshalb bekommst du im Szenario iss >> cmd; getline(iss, rest); fast immer ein führendes Leerzeichen in rest. Das lässt sich mit einfachem Trim beheben oder mit einem bewussten Formatvertrag: „nach dem Befehl ist genau ein Leerzeichen erlaubt“.
Fehler Nr.2: „leeres Feld“ und „fehlendes Feld“ verwechseln.
Die Zeichenfolge "a;;b" enthält drei Felder, wobei das zweite leer ist. Die Zeichenfolge "a;b" hat zwei Felder. Wenn du leere Felder unbedacht ignorierst, verschiebst du Spalten und interpretierst die Daten anschließend falsch. Selbst wenn du dich entscheidest, leere Felder zu überspringen, tue es bewusst und konsistent.
Fehler Nr.3: versuchen, ein mit ; oder , getrenntes Format mit operator>> zu parsen.
operator>> trennt standardmäßig nach Whitespace. Komma und Semikolon sind für ihn normale Zeichen innerhalb eines Tokens. Am Ende erhältst du ein „Stück String“, in dem noch die Separatoren stecken, und beginnst manuelle, schmerzhafte Nacharbeit. Für Separatoren nutze getline(..., delim).
Fehler Nr.4: den leeren Rest nach "add" nicht prüfen.
Der Befehl "add" ohne Text sieht nach einem Benutzerfehler aus. Wenn du nicht text.empty() prüfst, fügst du eine leere Aufgabe hinzu, zeigst sie in "list" und der Benutzer denkt, das Programm sei verrückt. Tatsächlich ist das Format das Problem, du musst einen Wächter an den Eingang setzen.
Fehler Nr.5: Anführungszeichen aus den Daten mit Anführungszeichen aus C++‑Literals verwechseln.
Der Benutzer gibt add "milk chocolate" ein. Du schreibst im Code "add \"milk chocolate\"". Wenn du diese Ebenen verwechselst, könntest du anfangen, vom Benutzer zu verlangen, dass er \" eingibt — und das macht die Oberfläche nahezu unbenutzbar. Merke: Backslashes sind ein Mittel, um Anführungszeichen im C++‑Source zu kodieren, nicht eine Regel für Benutzereingaben.
GO TO FULL VERSION