Dlaczego iostream :: eof wewnątrz warunku pętli (tj. `While (! Stream.eof ())`) jest uważany za niewłaściwy?

Właśnie znalazłem komentarz w tej odpowiedzi, który mówi, że używanie iostream::eofw pętli jest „prawie na pewno złe”. Zasadniczo używam czegoś takiego while(cin>>n)- co domyślnie sprawdza EOF.

Dlaczego jawne sprawdzanie eofa jest while (!cin.eof())nieprawidłowe?

Czym różni się od używania scanf("...",...)!=EOFw C (z którego często korzystam bez problemów)?

Ponieważ iostream::eofwróci dopiero true po przeczytaniu końca strumienia. To nie nie wskazuje, że następny odczyt będzie koniec strumienia.

Zastanów się (i załóż, że następny odczyt będzie na końcu strumienia):

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
}

Przeciwko temu:

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)
}

I na twoje drugie pytanie: Ponieważ

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

jest taki sam jak

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

i nie to samo co

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

Konkluzja: Przy prawidłowym obchodzeniu się z białą przestrzenią można zastosować następujące metody eof(a nawet być bardziej niezawodne niż fail()przy sprawdzaniu błędów):

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

( Dzięki Tony D za sugestię podkreślenia odpowiedzi. Zobacz jego komentarz poniżej, aby dowiedzieć się, dlaczego jest to bardziej niezawodne ).

Głównym argumentem przeciwko używaniu eof()wydaje się być brak ważnej subtelności na temat roli białej przestrzeni. Moja propozycja polega na tym, że eof()jawne sprawdzanie nie tylko „nie zawsze jest błędne ” - co wydaje się być nadrzędną opinią w tym i podobnych wątkach SO - ale także przy prawidłowej obsłudze białych znaków zapewnia czystsze i bardziej niezawodne obsługa błędów i jest zawsze poprawnym rozwiązaniem (choć niekoniecznie najkrótszym).

Podsumowując, co sugeruje się jako „prawidłowe” zakończenie i kolejność odczytu, należy:

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

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

Niepowodzenie spowodowane próbą odczytu poza eof jest traktowane jako warunek zakończenia. Oznacza to, że nie ma łatwego sposobu na odróżnienie udanego strumienia od takiego, który naprawdę zawodzi z powodów innych niż eof. Weź następujące strumienie:

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

while(in>>data)kończy się zestawem failbitdla wszystkich trzech wejść. W pierwszym i trzecimeofbit ustawiono również. Tak więc poza pętlą potrzebna jest bardzo brzydka dodatkowa logika, aby odróżnić prawidłowe dane wejściowe (1.) od niewłaściwych (2. i 3.).

Podczas gdy weź następujące:

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

Tutaj, in.fail() sprawdza, czy dopóki coś jest do przeczytania, jest to poprawne. Jego celem nie jest zwykły terminator pętli while.

Jak dotąd tak dobrze, ale co się stanie, jeśli w strumieniu pozostanie wolna przestrzeń - co wydaje się być głównym problemem eof() terminatorowi?

Nie musimy rezygnować z obsługi błędów; po prostu zjedz białą przestrzeń:

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::wspomija wszelkie potencjalne (zero lub więcej) końcowe miejsce w strumieniu podczas ustawiania eofbit, a niefailbit . in.fail()Działa więc zgodnie z oczekiwaniami, o ile istnieje co najmniej jedno dane do odczytania. Jeśli dopuszczalne są również całkowicie puste strumienie, wówczas poprawna forma to:

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
}

Podsumowanie: Prawidłowo skonstruowany while(!eof)jest nie tylko możliwy i niepoprawny, ale umożliwia lokalizację danych w zakresie i zapewnia bardziej czyste oddzielenie sprawdzania błędów od działalności w zwykły sposób. To powiedziawszy, while(!fail)jest bez wątpienia bardziej powszechnym i zwięzłym idiomem i może być preferowane w prostych scenariuszach (pojedyncze dane na typ odczytu).

Ponieważ jeśli programiści nie piszą while(stream >> n), prawdopodobnie piszą to:

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

Problem polega na tym, że nie można obejść się some work on nbez uprzedniego sprawdzenia, czy odczyt strumienia się powiódł, ponieważ jeśli się nie powiedzie, some work on nwynik byłby niepożądany.

Istotą jest to, że eofbit, badbitalbo failbitsą po podejmowana jest próba odczytu z potoku. Jeśli więc stream >> nzawiedzie eofbit,badbit lub failbitjest ustawiane natychmiast, więc jest bardziej idiomatyczne, jeśli piszesz while (stream >> n), ponieważ zwracany obiekt streamkonwertuje na, falsejeśli wystąpił błąd odczytu ze strumienia i w konsekwencji pętla zatrzymuje się. Konwertuje się na to, trueczy odczyt się powiódł i pętla trwa.

Inne odpowiedzi wyjaśniły, dlaczego logika jest błędna while (!stream.eof())i jak to naprawić. Chcę się skupić na czymś innym:

dlaczego jawne sprawdzanie eofa jest iostream::eofnieprawidłowe?

Ogólnie rzecz biorąc, sprawdzanie eof tylko jest niepoprawne, ponieważ ekstrakcja strumienia ( >>) może się nie powieść bez uderzania w koniec pliku. Jeśli masz np. int n; cin >> n;A strumień zawiera hello, hto nie jest prawidłową cyfrą, więc wyodrębnienie zakończy się niepowodzeniem bez dotarcia do końca danych wejściowych.

Ten problem, w połączeniu z ogólnym błędem logicznym sprawdzania stanu strumienia przed próbą odczytu z niego, co oznacza, że ​​dla N elementów wejściowych pętla będzie działać N + 1 razy, prowadzi do następujących symptomów:

• Jeśli strumień jest pusty, pętla uruchomi się raz. >>zawiedzie (nie ma danych wejściowych do odczytania) i wszystkie zmienne, które miały zostać ustawione (wgstream >> x ), są w rzeczywistości niezainicjowane. Prowadzi to do przetwarzania śmieciowych danych, co może przejawiać się jako nonsensowne wyniki (często ogromne liczby).

  (Jeśli twoja standardowa biblioteka jest zgodna z C ++ 11, sprawy wyglądają teraz trochę inaczej: błąd nie >>ustawia teraz zmiennych numerycznych 0zamiast pozostawiać je niezainicjowane (z wyjątkiem chars).)

• Jeśli strumień nie jest pusty, pętla uruchomi się ponownie po ostatnim prawidłowym wejściu. Ponieważ w ostatniej iteracji wszystkie >>operacje kończą się niepowodzeniem, zmienne prawdopodobnie zachowają swoją wartość z poprzedniej iteracji. Może się to objawiać jako „ostatni wiersz jest drukowany dwukrotnie” lub „ostatni rekord wejściowy jest przetwarzany dwa razy”.

  (Powinno to wyglądać nieco inaczej niż w C ++ 11 (patrz wyżej): Teraz otrzymujesz „widmowy rekord” zera zamiast powtarzanego ostatniego wiersza.)

• Jeśli strumień zawiera zniekształcone dane, ale tylko je sprawdzasz .eof, powstaje nieskończona pętla. >>nie uda się wyodrębnić żadnych danych ze strumienia, więc pętla obraca się w miejscu, nie osiągając nigdy końca.

Reasumując: Rozwiązaniem jest przetestować sukces >>samej operacji, aby nie stosować oddzielną .eof()metodę: while (stream >> n >> m) { ... }podobnie jak w C przetestować sukces scanfsamego połączenia: while (scanf("%d%d", &n, &m) == 2) { ... }.