ich habe eine Frage zu den IOStreams, speziell zu den Arithmetic Extractors.

Das exakte Regelwerk ist zwar in "Standard C++ IOStreams and Locales" und dem Standard selbst genau beschrieben, allerdings komme ich an einer Stelle ans Grübeln warum die Entscheidung so gefällt wurde.

Es geht genau um das hier:

int i;
cin >> i;

funktioniert wunderbar (failbit nicht gesetzt), auch wenn man z.B. 123abc eingibt (in i steht dann 123). Ich würde die gewagte Behauptung aufstellen wollen, das ist nicht das was man natürlich erwarten würde. Warum wird das Extrahieren nicht gestoppt, wenn man auf ein Whitespace trifft; bzw. mit failbit abgebrochen wenn man auf ungültige Daten trifft? Ich könnte mir vorstellen, dass man ungültige Zeichen nicht einfach verbrauchen will und diese dann verloren gehen, da man immer nur maximal ein Zeichen wieder zurück in den Stream legen kann.
Allerdings würde ich hier gerne mal eine genaue Begründung oder Diskussion über das Für und Wider lesen. Eine google-groups Suche nach den üblichen Verdächtigen (Dietmar Kühl ) liefert leider viel zu viel Mist, um das alles durchzuschauen.

MfG

Die Frage ist ja genau - warum ist es dort nicht "nötig" einen Fehler zu melden?

Was ich mir wie gesagt vorstellen kann ist folgendes:

- Input ist 123abc
- 123 wurde gelesen
- a wird über peek gesehen und als ungültig abgetan
- Da bis hierhin potenziell/wahrscheinlich schon mehr als ein Zeichen gelesen wurde, kann man es nicht einfach wieder zurück in den Stream legen, da das im Standard festgesetzte Limit nur ein Zeichen ist (nehmen wir mal an wir lesen unbuffered von einem Bandlaufwerk). Die bisher gelesene Information darf aber auch auf keinen Fall verloren gehen. D.h. man darf den Stream nicht auf Error setzen und muss die Information (123) speichern.

Aber das ist eben nur meine Vermutung. Gibt es keine archivierten Diskussionen der Standardlibrary-Designer, warum genau das so gemacht wurde? Ich kann mir viel zusammen reimen, aber ein offizielles Statement ist das was ich suche.

Warum wird das Extrahieren nicht gestoppt, wenn man auf ein Whitespace trifft; bzw. mit failbit abgebrochen wenn man auf ungültige Daten trifft?

Warum sollte man das denn generell wollen?
Es muß sowieso immer ein Zeichen mehr eingelesen werden, um das Ende einer Zahl zu erkennen (ob nun Leerzeichen, Zeilenende, Buchstabe oder sonstiges Zeichen) und der interne Lesezeiger bleibt einfach an dieser Stelle.

Deiner Aussage nach müßten dann ja alle Zahlen immer mit Whitespaces abgeschlossen werden. Dann wäre aber gerade das Extrahieren von Zahlen z.B. aus einem Dateinamen "Test4711.txt" extrem aufwändig.

Was ich mir vorstellen könnte, wäre die Einführung eines Flags (Manipulators), welches entscheidet, ob failbit gesetzt wird (bzw. eine Exception geworfen wird).

Warum sollte man das denn generell wollen?

Naja, weil es zumindest der natürlichen/alltäglichen/menschlichen Wahrnehmung einer Zahl entspricht (behaupte ich). Generell wollen - okay, soweit will nicht gehen, da es ja auch anders, wie du schreibst, Sinn macht.

Th schrieb:

Deiner Aussage nach müßten dann ja alle Zahlen immer mit Whitespaces abgeschlossen werden. Dann wäre aber gerade das Extrahieren von Zahlen z.B. aus einem Dateinamen "Test4711.txt" extrem aufwändig.

Hmm, gutes Argument.

Th schrieb:

Was ich mir vorstellen könnte, wäre die Einführung eines Flags (Manipulators), welches entscheidet, ob failbit gesetzt wird (bzw. eine Exception geworfen wird).

Das wäre auch noch was. Wäre dann in sofern überflüssig wenn es so funktioniert wie jetzt man man die Prüfung selber macht.

Außerdem halte ich es z-B. für sinnvoll, Zahlen mit angehängten Einheitsbezeichnern einlesen zu können.

12.3km
    -0.09m
    12°C
    34°F

Das geht nur dann ohne Kopfstände, wenn man die Zahl ohne Fehler lesen kann und anschließend die Zeichen dahinter auswertet, um ggf. die Zahl nochmal mit einem Faktor zu multiplizieren.

Gruß
Werner