Seltsames vorgehen bei Eingabe von String KLASSEN

out schrieb:

3. Du willst einen int einlesen. Der extraction operator ist clever und überließt (lesen + verwerfen) Whitespaces, die am Anfang stehen (führende Whitespaces). Somit gibt es im Puffer nun nur noch 99<Enter> . Die 99 wird gelesen, das Enter bricht den Einlesevorgang ab.
Ergebnis: Ein int 99 und ~~der Puffer ist nun leer!~~

Ups einen Fehler gemacht. Der Puffer ist nicht leer. Das doofe Enter steht noch drin. Nun kannst du z.B. cin.ignore(1) machen, damit der Puffer leer wird.

Nathan schrieb:

o90o90o90o schrieb:

Nicht so dumm wie du.
Erklär doch mal diese Ausgabe mit dem angeblich einheitlichen Whitespace Separator.

Da gibts nichts zu erklären, weil das genau dem Konzept des einheitlichen Whitespace Seperator entspricht.

So, k ist also ein Whitespace

Wieso diskutier ich überhaupt mit einem, der cout flusht bevor er einliest?

Hab den Code von seldon kopiert.

Nathan

Beantworte meine Frage: Was erwartest du?

"Formatierte Eingabe" heißt nicht zwingend, dass an Whitespaces abgebrochen wird.

Also, mal ganz von vorne, damit es verständlich ist: Eine formatierte Eingabefunktion ist datentypabhängig, nicht streamabhängig (streng genommen bei den Basistypen streitbar, aber das sind Implementationsdetails). Das Verhalten von cin >> str; (wenn std::string str) definiert nicht das Modul basic_istream, sondern das Modul basic_string. Wenn du einen std::complex<double> einliest, definiert auch dessen operator>> und nicht der Stream, was konsumiert wird (und dabei werden auch Whitespaces konsumiert).

Der Vorteil dieser Herangehensweise ist: Es ist egal, aus was für einem Stream du Strings, komplexe Zahlen oder Objekte deines eigenen Datentypens einlesen willst, du musst nur einen operator>> schreiben und kannst fortan aus std::istringstream, std::ifstream und allem anderen, was std::istream erbt, einlesen (Stichwort Liskov-Substitutierbarkeit).

Die formatierte Eingabefunktion von std::string definiert sich, und das ist auch in anderen Sprachen durchaus üblich, auf Basis von Tokens, nicht Zeilen -- und erst hier kommt der Abbruch bei Whitespaces ins Spiel. Wenn man die Abstraktion kennt (was man sollte) und das ganze als "ich hab einen Datenstrom, jetzt hol ich mir den nächsten String daraus" liest (was man sollte), ist es auch das, was man intuitiv erwartet. Hier eine Sonderlösung für CLIs hinzuklatschen, das wäre aus meiner Sicht wenig sinnvoll.

Zum Thema Dateien: Eine Datei ist im Standard definiert als "A File provides an external source/sink stream whose underlaid character type is char (byte)." stdin und stdout fallen darunter, seek hat nichts damit zu tun (und ist hauptsächlich auf der Untermenge sog. "regulärer Dateien" von Belang). Aber bevor wir hier in Wortspiele verfallen: Der relevante Punkt ist, dass man für den Großteil aller Operationen die Konsole genauso behandeln können will wie eine reguläre Datei, eine FIFO oder ein Netzwerksocket, denn dann muss man seinen Code nicht doppelt und dreifach schreiben.

Zum Thema Flush: std::flush sollte in diesem Zusammenhang nicht notwendig sein, weil std::cout an std::cin getied ist und ein Einlesen aus std::cin dazu führt, dass std::cout automatisch geflusht wird (falls notwendig, wenn die Implementation schlau ist), aber mir sind schon (alte) Implementationen untergekommen, die das nicht so genau nehmen. Wobei die inzwischen nicht mehr relevant sein dürften, so dass ich mir das vielleicht mal abgewöhnen sollte. Tut aber nicht wirklich weh.

seldon schrieb:

Das Verhalten von cin >> str; (wenn std::string str) definiert nicht das Modul basic_istream, sondern das Modul basic_string.
[...]
Die formatierte Eingabefunktion von std::string definiert sich, und das ist auch in anderen Sprachen durchaus üblich, auf Basis von Tokens, nicht Zeilen -- und erst hier kommt der Abbruch bei Whitespaces ins Spiel.

Ja, wenn man es oberflächlich betrachtet, stimmt das so.

Genau genommen kommuniziert das Modul basic_string (wie auch für andere Module empfohlen) mit basic_istream (bzw. dessen locale) um das gewünschte Verhalten zu zeigen. basic_string fragt zum Beispiel bei jedem operator>> an, was denn diesesmal als Whitespace gelten sollte und was nicht. Andere Klassen haben sogar deutlich mehr Interaktion mit den facetten von basic_istream, so könnte man zum Beispiel mit einem kleinen Handgriff ändern, dass alle Zahlen im römischen Zahlenformat gelesen werden, was dann auch std::complex betrifft.

Wenn man ganz pedantisch sein will, spricht basic_string mit locale, um herauszufinden, ob etwas ein Whitespace ist. std::complex bedient sich bei seinem Werttypen -- etwa wird std::complex<mpf_class> in der gmp nach einem operator>> suchen. (ich hab grad nachgekuckt, die haben keinen operator>> in der gmplib. Verdammt. Also, wenn sie einen hätten, dann würde std::complexs operator>> den in diesem Fall benutzen)

Letztendlich sind solche Details für den groben Überblick aber nicht entscheidend. Wenn ich einen eigenen Datentyp baue und einen operator>> bereitstelle, wird der in der Regel den operator>> anderer Typen für Objektteile verwenden. Nichtsdestoweniger gehört dieser operator>> organisatorisch zu meinem Datentypen; es wäre albern, ihn dem Stream oder den Klassen von Memberobjekten zuzuschlagen. Worauf ich damit hinauswill, ist, dass jeder Typ selbst definiert, wie er formatiert eingelesen werden kann, und dass das nicht zentralisiert beim Stream gemacht werden kann/sollte.

Nathan schrieb:

Beantworte meine Frage: Was erwartest du?

Das "123katzekatze678" kein int ist.

seldon schrieb:

"Formatierte Eingabe" heißt nicht zwingend, dass an Whitespaces abgebrochen wird.

Also, mal ganz von vorne, damit es verständlich ist: Eine formatierte Eingabefunktion ist datentypabhängig, nicht streamabhängig (streng genommen bei den Basistypen streitbar, aber das sind Implementationsdetails). Das Verhalten von cin >> str; (wenn std::string str) definiert nicht das Modul basic_istream, sondern das Modul basic_string. Wenn du einen std::complex<double> einliest, definiert auch dessen operator>> und nicht der Stream, was konsumiert wird (und dabei werden auch Whitespaces konsumiert).

Der Vorteil dieser Herangehensweise ist: Es ist egal, aus was für einem Stream du Strings, komplexe Zahlen oder Objekte deines eigenen Datentypens einlesen willst, du musst nur einen operator>> schreiben und kannst fortan aus std::istringstream, std::ifstream und allem anderen, was std::istream erbt, einlesen (Stichwort Liskov-Substitutierbarkeit).

Die formatierte Eingabefunktion von std::string definiert sich, und das ist auch in anderen Sprachen durchaus üblich, auf Basis von Tokens, nicht Zeilen -- und erst hier kommt der Abbruch bei Whitespaces ins Spiel. Wenn man die Abstraktion kennt (was man sollte) und das ganze als "ich hab einen Datenstrom, jetzt hol ich mir den nächsten String daraus" liest (was man sollte), ist es auch das, was man intuitiv erwartet. Hier eine Sonderlösung für CLIs hinzuklatschen, das wäre aus meiner Sicht wenig sinnvoll.

Warum sollte es dann intuitiv sein, dass Space ein string Separator ist, wenn du schon sagst, dass man den Operator beliebig für jeden Datentyp schreiben kann? Warum sollte "123katzekatze678" dann ein int und ein string sein? Da sind garkeine Whitespaces drin.

otze

ich muss mich anschließen:

Das Verhalten von op>> ist nicht intuitiv. Entweder "123katzekatze678" zerfällt in int-string-int oder ist eine fehlerhafte Eingabe. Wenn white space eine bedeutung hat, dann als "123 katzekatze 678".

Shade Of Mine

otze schrieb:

ich muss mich anschließen:

Das Verhalten von op>> ist nicht intuitiv. Entweder "123katzekatze678" zerfällt in int-string-int oder ist eine fehlerhafte Eingabe. Wenn white space eine bedeutung hat, dann als "123 katzekatze 678".

Ne, ein int-string-int wäre absolut bescheuert. Nix für ungut. Es ist int-string und das ist es auch.

ein cin>>int>>string liefert dir hier int==123 und string==katzekatze678
genau das korrekte verhalten.

Die Operatoren arbeiten schon korrekt weil konsistent. Die hier vorgeschlagenen anderen Erwartungen an den op>> sind ziemlich dämlich.

Kennst du irgendeine andere Sprache/Library, bei der "123katzekatze678" ein int und ein string ist?

Shade Of Mine

o90o90o90o schrieb:

Kennst du irgendeine andere Sprache/Library, bei der "123katzekatze678" ein int und ein string ist?

Klar, jede Sprache.

Man hat normalerweise halt keine generischen extraktoren wie der op>> aber zB ein parseInt in JavaScript auf "123katze" liefert dir 123 als Ergebnis.

In Java funktioniert Scanner zB sehr ähnlich zum op>> in C++.

Eigentlich kenne ich keine Sprache wo "123katze" als integer interpretiert nicht 123 liefert. Kennst du eine?

Shade Of Mine schrieb:

Die Operatoren arbeiten schon korrekt weil konsistent. Die hier vorgeschlagenen anderen Erwartungen an den op>> sind ziemlich dämlich.

1. Nur weil etwas konsistent ist, ist es noch lange nicht korrekt.
2. Was ist daran überhaupt konsistent? int endet anscheinend bei jedem Zeichen, dass nicht als int interpretiert werden kann. string endet bei Whitespace. Das einzige was da konsistent ist, ist dass es nicht intuitiv ist.

Shade Of Mine schrieb:

o90o90o90o schrieb:

Kennst du irgendeine andere Sprache/Library, bei der "123katzekatze678" ein int und ein string ist?

Klar, jede Sprache.

Man hat normalerweise halt keine generischen extraktoren wie der op>> aber zB ein parseInt in JavaScript auf "123katze" liefert dir 123 als Ergebnis.

In Java funktioniert Scanner zB sehr ähnlich zum op>> in C++.

Eigentlich kenne ich keine Sprache wo "123katze" als integer interpretiert nicht 123 liefert.

Ich hab zwar Java Scanner noch nie verwendet, aber habs mal getestet und 123katze ist kein int.

/* package whatever; // don't place package name! */

    import java.io.File;
    import java.io.FileNotFoundException;
    import java.util.Scanner;

    /* Name of the class has to be "Main" only if the class is public. */
    class Ideone
    {
    public static void main (String[] args) throws java.lang.Exception
    {

    Scanner scanner = new Scanner(System.in);

    int i = scanner.nextInt();
    System.out.println(i);

    System.out.println("Bye...");
    scanner.close();
    }
    }

ideone macht bei copy&paste die formatierung kaputt.

http://ideone.com/dXEHYC

Success #stdin #stdout 0.1s 380736KB
comments (?)
stdin
copy

123

stdout
copy

123
Bye...

http://ideone.com/zBLf25

Runtime error #stdin #stdout #stderr 0.1s 380672KB
comments (?)
stdin
copy

123katze

stdout

Standard output is empty

stderr

Exception in thread "main" java.util.InputMismatchException
at java.util.Scanner.throwFor(Scanner.java:909)
at java.util.Scanner.next(Scanner.java:1530)
at java.util.Scanner.nextInt(Scanner.java:2160)
at java.util.Scanner.nextInt(Scanner.java:2119)
at Ideone.main(Main.java:15)

Kennst du eine?

Java

Ich hab jetzt keine Lust mehr auf den Quatsch und eure falschen Behauptungen zu überprüfen. Wenn ihr meint, dass 123katze ein int sein sollte, dann viel Spass bei euren Kunden.