Warum wird iostream :: eof innerhalb einer Schleifenbedingung (dh `while (! Stream.eof ())`) als falsch angesehen?

Ich habe gerade einen Kommentar in dieser Antwort gefunden, der besagt, dass die Verwendung iostream::eofin einer Schleifenbedingung "mit ziemlicher Sicherheit falsch" ist. Ich benutze im Allgemeinen so etwas wie while(cin>>n)- was ich implizit auf EOF prüfe.

Warum wird die Überprüfung auf eof explizit while (!cin.eof())falsch verwendet?

Wie unterscheidet es sich von der Verwendung scanf("...",...)!=EOFin C (die ich oft ohne Probleme verwende)?

Denn iostream::eofwird erst true nach dem Lesen des Stream-Endes zurückkehren. Es zeigt nicht an, dass der nächste Lesevorgang das Ende des Streams sein wird.

Bedenken Sie dies (und nehmen Sie an, dass der nächste Lesevorgang am Ende des Streams erfolgt):

while(!inStream.eof()){
  int data;
  // yay, not end of stream yet, now read ...
  inStream >> data;
  // oh crap, now we read the end and *only* now the eof bit will be set (as well as the fail bit)
  // do stuff with (now uninitialized) data
}

Gegen das:

int data;
while(inStream >> data){
  // when we land here, we can be sure that the read was successful.
  // if it wasn't, the returned stream from operator>> would be converted to false
  // and the loop wouldn't even be entered
  // do stuff with correctly initialized data (hopefully)
}

Und zu Ihrer zweiten Frage: Weil

if(scanf("...",...)!=EOF)

ist das gleiche wie

if(!(inStream >> data).eof())

und nicht das gleiche wie

if(!inStream.eof())
    inFile >> data

Fazit oben: Bei richtiger Behandlung von Leerzeichen kann Folgendes eofverwendet werden (und sogar zuverlässiger sein als fail()bei der Fehlerprüfung):

while( !(in>>std::ws).eof() ) {  
   int data;
   in >> data;
   if ( in.fail() ) /* handle with break or throw */; 
   // now use data
}    

( Vielen Dank an Tony D für den Vorschlag, die Antwort hervorzuheben. In seinem Kommentar unten finden Sie ein Beispiel dafür, warum dies robuster ist. )

Dem Hauptargument gegen die Verwendung eof()scheint eine wichtige Subtilität über die Rolle des Leerraums zu fehlen. Mein Vorschlag ist, dass eof()explizites Prüfen nicht nur nicht " immer falsch " ist - was in diesem und ähnlichen SO-Threads eine übergeordnete Meinung zu sein scheint -, sondern bei ordnungsgemäßem Umgang mit Leerraum auch für einen saubereren und zuverlässigeren Umgang sorgt Fehlerbehandlung und ist die immer richtige Lösung (obwohl nicht unbedingt die engste).

Um zusammenzufassen, was als "richtige" Kündigungs- und Lesereihenfolge vorgeschlagen wird, ist Folgendes:

int data;
while(in >> data) {  /* ... */ }

// which is equivalent to 
while( !(in >> data).fail() )  {  /* ... */ }

Der Fehler aufgrund eines Leseversuchs über eof hinaus wird als Beendigungsbedingung angesehen. Dies bedeutet, dass es keine einfache Möglichkeit gibt, zwischen einem erfolgreichen Stream und einem Stream zu unterscheiden, der aus anderen Gründen als eof wirklich fehlschlägt. Nehmen Sie die folgenden Streams:

• 1 2 3 4 5<eof>
• 1 2 a 3 4 5<eof>
• a<eof>

while(in>>data)endet mit einem Satz failbitfür alle drei Eingänge. Im ersten und dritten eofbitwird auch gesetzt. Nach der Schleife braucht man also eine sehr hässliche zusätzliche Logik, um einen richtigen Eingang (1.) von einem falschen (2. und 3.) zu unterscheiden.

Nehmen Sie Folgendes:

while( !in.eof() ) 
{  
   int data;
   in >> data;
   if ( in.fail() ) /* handle with break or throw */; 
   // now use data
}    

Hier wird in.fail()überprüft, ob etwas zu lesen ist, es ist das richtige. Sein Zweck ist nicht nur ein While-Loop-Terminator.

So weit so gut, aber was passiert, wenn im Stream nachlaufender Speicherplatz vorhanden ist - was klingt nach der größten Sorge eof()als Terminator?

Wir müssen unsere Fehlerbehandlung nicht aufgeben. iss einfach den Leerraum auf:

while( !in.eof() ) 
{  
   int data;
   in >> data >> ws; // eat whitespace with std::ws
   if ( in.fail() ) /* handle with break or throw */; 
   // now use data
}

std::wsÜberspringt jeglichen potenziellen (null oder mehr) nachgestellten Speicherplatz im Stream, während das eofbitund nicht das festgelegt wirdfailbit . Funktioniert also in.fail()wie erwartet, solange mindestens eine Daten gelesen werden muss. Wenn auch leere Streams akzeptabel sind, lautet die richtige Form:

while( !(in>>ws).eof() ) 
{  
   int data;
   in >> data; 
   if ( in.fail() ) /* handle with break or throw */; 
   /* this will never fire if the eof is reached cleanly */
   // now use data
}

Zusammenfassung: Eine ordnungsgemäß erstellte Konstruktion while(!eof)ist nicht nur möglich und nicht falsch, sondern ermöglicht auch die Lokalisierung von Daten innerhalb des Gültigkeitsbereichs und bietet eine sauberere Trennung von Fehlerprüfung und Business as usual. Davon abgesehen, while(!fail)ist inarguably ein häufige und terse Idiom und kann in einfachen (Einzeldaten pro Lesetyp) Szenarien bevorzugt sein.

Denn wenn Programmierer nicht schreiben while(stream >> n), schreiben sie möglicherweise Folgendes:

while(!stream.eof())
{
    stream >> n;
    //some work on n;
}

Hier besteht das Problem darin, dass Sie nicht darauf verzichten müssen, some work on nzuerst zu überprüfen, ob das Lesen des Streams erfolgreich war. Wenn dies nicht erfolgreich war, some work on nwürde dies zu unerwünschten Ergebnissen führen.

Der springende Punkt ist , dass, eofbit, badbit, oder failbiteingestellt werden , nachdem ein Versuch gemacht wird , aus dem Stream zu lesen. Also , wenn stream >> nnicht, dann eofbit, badbitoder failbitsofort gesetzt wird, so dass ihre mehr idiomatischen , wenn Sie schreiben while (stream >> n), weil das zurückgegebene Objekt streamKonvertiten , falsewenn irgendein Fehler war aus dem Strom in dem Lese und damit die Schleife beendet. Und es wird konvertiert, truewenn der Lesevorgang erfolgreich war und die Schleife fortgesetzt wird.

Die anderen Antworten haben erklärt, warum die Logik falsch ist while (!stream.eof())und wie man sie behebt. Ich möchte mich auf etwas anderes konzentrieren:

Warum wird die Überprüfung auf eof explizit iostream::eoffalsch verwendet?

Im Allgemeinen ist die Überprüfung eof nur auf falsch, da die Stream-Extraktion ( >>) fehlschlagen kann, ohne das Ende der Datei zu erreichen. Wenn Sie zB haben int n; cin >> n;und der Stream enthält hello, hist dies keine gültige Ziffer, sodass die Extraktion fehlschlägt, ohne das Ende der Eingabe zu erreichen.

Dieses Problem führt zusammen mit dem allgemeinen logischen Fehler, den Stream-Status vor dem Versuch, daraus zu lesen, zu überprüfen , was bedeutet, dass die Schleife für N Eingabeelemente N + 1 Mal ausgeführt wird, zu den folgenden Symptomen:

• Wenn der Stream leer ist, wird die Schleife einmal ausgeführt. >>wird fehlschlagen (es gibt keine zu lesende Eingabe) und alle Variablen, die gesetzt werden sollten (von stream >> x), sind tatsächlich nicht initialisiert. Dies führt dazu, dass Mülldaten verarbeitet werden, die sich als unsinnige Ergebnisse (häufig große Zahlen) manifestieren können.

  (Wenn Ihre Standardbibliothek C ++ 11 entspricht, sind die Dinge jetzt etwas anders: Ein Fehler >>setzt jetzt numerische Variablen auf, 0anstatt sie nicht initialisiert zu lassen (mit Ausnahme von chars).)

• Wenn der Stream nicht leer ist, wird die Schleife nach der letzten gültigen Eingabe erneut ausgeführt. Da in der letzten Iteration alle >>Operationen fehlschlagen, behalten Variablen wahrscheinlich ihren Wert aus der vorherigen Iteration bei. Dies kann sich als "die letzte Zeile wird zweimal gedruckt" oder "der letzte Eingabedatensatz wird zweimal verarbeitet" manifestieren.

  (Dies sollte sich seit C ++ 11 etwas anders manifestieren (siehe oben): Jetzt erhalten Sie einen "Phantom Record" von Nullen anstelle einer wiederholten letzten Zeile.)

• Wenn der Stream fehlerhafte Daten enthält, Sie aber nur nachsehen .eof, erhalten Sie eine Endlosschleife. >>Es werden keine Daten aus dem Stream extrahiert, sodass sich die Schleife dreht, ohne jemals das Ende zu erreichen.

Um es noch einmal zusammenzufassen: Die Lösung besteht darin, den Erfolg der >>Operation selbst zu testen und keine separate .eof()Methode zu verwenden: while (stream >> n >> m) { ... }Genau wie in C testen Sie den Erfolg des scanfAufrufs selbst : while (scanf("%d%d", &n, &m) == 2) { ... }.