Warum wird iostream::eof innerhalb einer Schleifenbedingung (d. h. `while (!stream.eof())`) als falsch angesehen?

Question

Ich habe gerade einen Kommentar in este Antwort, dass die Verwendung von iostream::eof in einer Schleifenbedingung ist "mit ziemlicher Sicherheit falsch". Ich verwende im Allgemeinen etwas wie while(cin>>n) - was wohl implizit auf EOF prüft.

Warum wird die Prüfung auf eof explizit mit while (!cin.eof()) falsch?

Was ist der Unterschied zur Verwendung von scanf("...",...)!=EOF in C (die ich oft ohne Probleme verwende)?

Answer 1

Denn iostream::eof wird nur zurückgegeben true nach Lesen des Endes des Streams. Es tut no zeigen an, dass der nächste Lesevorgang das Ende des Datenstroms sein wird.

Stellen Sie sich Folgendes vor (und gehen Sie davon aus, dass das nächste Lesen am Ende des Streams stattfindet):

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
}

Dagegen:

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 dasselbe wie

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

y no dasselbe wie

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

Answer 2

Unterm Strich oben: Bei ordnungsgemäßer Handhabung des Leerzeichens sieht das folgendermaßen aus eof verwendet werden können (und sogar zuverlässiger sind als fail() zur Fehlerprüfung):

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

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

---

Das Hauptargument gegen die Verwendung eof() scheint eine wichtige Feinabstimmung über die Rolle des Weißraums zu fehlen. Mein Vorschlag ist, dass bei der Überprüfung eof() ist nicht nur ausdrücklich nicht " immer falsch " -- was eine vorherrschende Meinung in diesem und ähnlichen SO-Threads zu sein scheint --, aber mit der richtigen Behandlung von Leerzeichen sorgt es für eine sauberere und zuverlässigere Fehlerbehandlung und ist die immer richtig Lösung (auch wenn sie nicht unbedingt die kürzeste ist).

Zusammenfassend kann man sagen, dass die "richtige" Reihenfolge der Beendigung und des Lesens wie folgt aussieht:

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

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

Das Scheitern eines Leseversuchs nach eof wird als Abbruchbedingung 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 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 failbit para todo drei Eingaben. In der ersten und dritten, eofbit ist ebenfalls festgelegt. Hinter der Schleife braucht man also eine sehr hässliche zusätzliche Logik, um eine richtige Eingabe (1.) von einer falschen (2. und 3.) zu unterscheiden.

Nehmen Sie dagegen Folgendes an:

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

Hier, in.fail() bestätigt, dass, solange es etwas zu lesen gibt, es auch das Richtige ist. Er dient nicht nur als Begrenzer der while-Schleife.

So weit, so gut, aber was passiert, wenn im Datenstrom Leerzeichen vorhanden sind - das klingt nach dem Hauptproblem gegen eof() als Terminator?

Wir müssen unsere Fehlerbehandlung nicht aufgeben, sondern nur den Leerraum aufbrauchen:

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 jedes potenzielle (null oder mehr) Leerzeichen am Ende des Datenstroms, während es den eofbit y nicht die failbit . Also, in.fail() funktioniert wie erwartet, solange es mindestens eine Datei zu lesen gibt. Wenn auch "All-Blank"-Streams akzeptabel sind, dann ist die korrekte 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 richtig konstruierte while(!eof) ist nicht nur möglich und nicht falsch, sondern ermöglicht auch die Lokalisierung von Daten innerhalb des Geltungsbereichs und bietet eine saubere Trennung der Fehlerprüfung von der normalen Geschäftstätigkeit. Davon abgesehen, while(!fail) ist zweifellos eine gebräuchlichere und prägnantere Redewendung, die in einfachen Szenarien (einzelne Daten pro Lesevorgang) bevorzugt werden kann.

Answer 3

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

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

Das Problem dabei ist, dass man nicht some work on n ohne vorher zu prüfen, ob das Lesen des Datenstroms erfolgreich war, denn wenn dies nicht der Fall war, wird Ihr some work on n würde zu einem unerwünschten Ergebnis führen.

Das ist der springende Punkt, eofbit , badbit o failbit eingestellt sind nachdem ein Leseversuch aus dem Stream unternommen wurde. Wenn also stream >> n fehlschlägt, dann eofbit , badbit o failbit wird sofort gesetzt, daher ist es idiomatischer, wenn Sie schreiben while (stream >> n) weil das zurückgegebene Objekt stream konvertiert zu false wenn ein Fehler beim Lesen des Datenstroms aufgetreten ist und die Schleife folglich anhält. Und sie konvertiert zu true wenn das Lesen erfolgreich war und die Schleife fortgesetzt wird.

Answer 4

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

warum wird die Prüfung auf eof explizit mit iostream::eof falsch?

Generell kann man sagen, dass die Prüfung auf eof nur ist falsch, weil die Stream-Extraktion ( >> ) kann fehlschlagen, ohne das Ende der Datei zu erreichen. Wenn Sie z.B. int n; cin >> n; und der Strom enthält hello entonces h ist keine gültige Ziffer, so dass die Extraktion fehlschlägt, ohne das Ende der Eingabe zu erreichen.

Dieses Problem in Verbindung mit dem allgemeinen Logikfehler bei der Überprüfung des Stromstatus 前 Der Versuch, daraus zu lesen, was bedeutet, dass die Schleife für N Eingabeelemente N+1 Mal durchlaufen wird, führt zu folgenden Symptomen:

• Wenn der Stream leer ist, wird die Schleife einmal durchlaufen. >> scheitert (es gibt keine zu lesende Eingabe) und alle Variablen, die gesetzt werden sollten (durch stream >> x ) sind eigentlich nicht initialisiert. Dies führt dazu, dass Datenmüll verarbeitet wird, der sich in unsinnigen Ergebnissen (oft riesigen Zahlen) äußern kann.

  (Wenn Ihre Standardbibliothek mit C++11 konform ist, liegen die Dinge jetzt etwas anders: Eine fehlgeschlagene >> setzt nun numerische Variablen auf 0 anstatt sie uninitialisiert zu lassen (außer bei char s).)

• Wenn der Stream nicht leer ist, wird die Schleife nach der letzten gültigen Eingabe erneut durchlaufen. Da in der letzten Iteration alle >> Operationen fehlschlagen, behalten die Variablen wahrscheinlich ihren Wert aus der vorherigen Iteration. Dies kann sich so äußern, dass "die letzte Zeile zweimal gedruckt" oder "der letzte Eingabesatz zweimal verarbeitet" wird.

  (Dies sollte sich seit C++11 ein wenig anders darstellen (siehe oben): Statt einer wiederholten letzten Zeile erhält man nun einen "Phantomsatz" aus Nullen).

• Wenn der Stream fehlerhafte Daten enthält, Sie aber nur auf .eof landet man in einer Endlosschleife. >> kann keine Daten aus dem Stream extrahieren, so dass die Schleife weiterläuft, ohne jemals das Ende zu erreichen.

---

Um es kurz zu machen: Die Lösung besteht darin, den Erfolg der >> Operation selbst, und nicht die Verwendung eines separaten .eof() Methode: while (stream >> n >> m) { ... } so wie man in C den Erfolg der Methode scanf selbst aufrufen: while (scanf("%d%d", &n, &m) == 2) { ... } .

Answer 5

Das Wichtigste ist, dass man sich daran erinnert, inFile.eof() wird nicht True bis nach ein Leseversuch scheitert, weil Sie das Ende der Datei erreicht haben. In diesem Beispiel erhalten Sie also eine Fehlermeldung.

while (!inFile.eof()){
    inFile >> x;
        process(x);
}

Um diese Schleife korrekt zu gestalten, müssen Lesen und Prüfen zu einem einzigen Vorgang zusammengefasst werden, und zwar wie folgt

while (inFile >> x) 
    process(x); 

Nach Konvention, operator>> gibt den Stream zurück, aus dem wir gelesen haben, und ein boolescher Test auf einen Stream gibt False wenn der Stream fehlschlägt (z. B. wenn das Ende der Datei erreicht wird).

Damit haben wir die richtige Reihenfolge:

• lesen
• prüfen, ob das Lesen erfolgreich war
• wenn und nur wenn der Test erfolgreich ist, verarbeiten Sie das Gelesene

Wenn Sie zufällig auf einige autre Wenn Sie ein Problem haben, das Sie daran hindert, die Datei korrekt zu lesen, können Sie die Datei nicht erreichen. eof() als solche. Betrachten wir zum Beispiel etwas wie dieses

int x; 
while (!inFile.eof()) { 
    inFile >> x; 
    process(x);
} 

Lassen Sie uns die Funktionsweise des obigen Codes anhand eines Beispiels nachvollziehen

• Angenommen, der Inhalt der Datei lautet '1', '2', '3', 'a', 'b' .
• Die Schleife liest die 1, 2 und 3 richtig.
• Dann wird es zu a .
• Wenn es versucht, die a als int, wird es scheitern.
• Der Strom ist jetzt in einem gescheiterten Zustand, bis oder solange wir clear der Stream, schlagen alle Versuche, ihn zu lesen, fehl.
• Aber wenn wir auf eof() testen, wird das Ergebnis False weil wir noch nicht am Ende der Datei sind, denn es gibt noch a die darauf warten, gelesen zu werden.
• Die Schleife wird immer wieder versuchen, aus der Datei zu lesen, und jedes Mal scheitern, so dass sie niemals das Ende der Datei erreicht.
• Die obige Schleife wird also ewig laufen.

Wenn wir jedoch eine Schleife wie diese verwenden, erhalten wir die gewünschte Ausgabe.

while (inFile >> x)
    process(x);

In diesem Fall wird der Stream in False nicht nur bei Dateiende, sondern auch bei einer fehlgeschlagenen Konvertierung, wie z. B. bei der a die wir nicht als Ganzzahl lesen können.