Why is " while (!feof (plik))" zawsze źle?

Chciałbym przedstawić abstrakcyjną, wysokopoziomową perspektywę.

Współbieżność i jednoczesność

Operacje wejścia/Wyjścia oddziałują na środowisko. Środowisko nie jest częścią twojego programu i nie jest pod twoją kontrolą. Środowisko naprawdę istnieje "równocześnie" z Twoim programem. Podobnie jak w przypadku wszystkich rzeczy współbieżnych, pytania o "obecny stan" nie mają sensu: nie ma pojęcia "symultaniczności" między zdarzeniami współbieżnymi. Wiele właściwości Państwa po prostu nie exist

Doprecyzuję to: przypuśćmy, że chcesz zapytać :" czy masz więcej danych". Możesz zapytać o to współbieżny kontener lub Twój system We/Wy. Ale odpowiedź jest na ogół nie do zastosowania, a więc bez znaczenia. Co z tego, jeśli kontener powie "tak" – zanim spróbujesz czytać, może nie mieć już danych. Podobnie, jeśli odpowiedź brzmi "nie", do czasu próby czytania, dane mogły już dotrzeć. Wniosek jest taki, że po prostu jest nie właściwości takie jak "mam dane", ponieważ nie można działać w sposób znaczący w odpowiedzi na jakąkolwiek możliwą odpowiedź. (Sytuacja jest nieco lepsza z buforowanym wejściem, gdzie można by przypuszczać, że "tak, mam dane" stanowi jakąś gwarancję, ale nadal musiałbyś być w stanie poradzić sobie z przeciwną sprawą. A z wyjściem sytuacja jest z pewnością tak zła, jak opisałem: nigdy nie wiadomo, czy dysk lub bufor sieciowy jest pełny.)

Wnioskujemy więc, że jest to niemożliwe, i w rzeczywistości unrozsądne, aby zapytać system we/wy, czy będzie on w stanie wykonać operację we/wy. Jedynym możliwym sposobem na interakcję z nim (tak jak z współbieżnym kontenerem) jest próba operacji i sprawdzenie, czy się powiodła, czy nie. W tym momencie, gdy wchodzicie w interakcję z otoczeniem, wtedy i tylko wtedy możecie wiedzieć, czy interakcja była rzeczywiście możliwa, i w tym momencie musicie zobowiązać się do przeprowadzenia interakcji. (To "punkt synchronizacji", jeśli wolisz.)

EOF

Teraz mamy EOF. EOF jest odpowiedzią otrzymywaną z próby operacji wejścia/Wyjścia. Oznacza to, że próbowałeś coś odczytać lub napisać, ale nie udało Ci się odczytać lub zapisać żadnych danych, a zamiast tego napotkano koniec wejścia lub wyjścia. Dotyczy to zasadniczo wszystkich interfejsów API we/wy, niezależnie od tego, czy jest to biblioteka standardowa C, iostreams C++, czy inne biblioteki. Dopóki operacje wejścia / Wyjścia sukces, po prostu nie możesz wiedzieć czy dalsze, przyszłe operacje odniosą sukces. Musisz zawsze najpierw spróbować operacji, a następnie odpowiedzieć na sukces lub porażkę.

Przykłady

W każdym z przykładów zwróć uwagę, że najpierw spróbujemy operacji wejścia/wyjścia i następnie pochłonie wynik, jeśli jest poprawny. Zauważ ponadto, że zawsze musimy użyć wyniku operacji We/Wy, chociaż wynik przybiera różne kształty i formularze w każdym przykładzie.

• C stdio, odczytane z pliku:

  for (;;) {
      size_t n = fread(buf, 1, bufsize, infile);
      consume(buf, n);
      if (n < bufsize) { break; }
  }
  

  Wynikiem, którego musimy użyć, jest n, liczba odczytanych elementów (która może wynosić nawet zero).

• C stdio, scanf:

  for (int a, b, c; scanf("%d %d %d", &a, &b, &c) == 3; ) {
      consume(a, b, c);
  }
  

  Wynikiem, którego musimy użyć, jest wartość zwracana scanf, liczba przekonwertowanych elementów.

• C++, iostreams sformatowany ekstrakcja:

  for (int n; std::cin >> n; ) {
      consume(n);
  }
  

  Wynik, którego musimy użyć to std::cin, który można ocenić w kontekście logicznym i mówi nam, czy strumień jest nadal w stanie good().

• C++, iostreams getline:

  for (std::string line; std::getline(std::cin, line); ) {
      consume(line);
  }
  

  Wynik, którego musimy użyć, jest ponownie std::cin, tak jak wcześniej.

• POSIX, write(2) do spłukiwania bufora:

  char const * p = buf;
  ssize_t n = bufsize;
  for (ssize_t k = bufsize; (k = write(fd, p, n)) > 0; p += k, n -= k) {}
  if (n != 0) { /* error, failed to write complete buffer */ }
  

  Wynikiem, którego tutaj używamy, jest k, liczba zapisanych bajtów. Chodzi o to, że możemy wiedzieć tylko ile bajtów zostało zapisanych Po operacji zapisu.

• POSIX getline()

  char *buffer = NULL;
  size_t bufsiz = 0;
  ssize_t nbytes;
  while ((nbytes = getline(&buffer, &bufsiz, fp)) != -1)
  {
      /* Use nbytes of data in buffer */
  }
  free(buffer);
  

  Wynikiem, którego musimy użyć, jest nbytes, liczba bajtów do nowej linii włącznie(lub EOF, jeśli plik nie zakończył się nową linią).

  Zauważ, że funkcja jawnie zwraca -1 (a nie EOF!) gdy wystąpi błąd lub osiągnie EOF.

Możesz zauważyć, że bardzo rzadko piszemy prawdziwe słowo "EOF". Zwykle wykrywamy stan błędu w inny sposób, który jest dla nas bardziej interesujący (np. brak wykonania tak dużej ilości We / Wy, jak sobie tego życzyliśmy). W każdym przykładzie jest jakaś funkcja API, która może nam wyraźnie powiedzieć, że stan EOF został napotkany, ale w rzeczywistości nie jest to zbyt przydatna informacja. To o wiele więcej szczegółów, niż nam często zależy. Najważniejsze jest to, czy I/O się powiodło się, bardziej niż jak się nie powiodło.

• Ostatni przykład, który faktycznie zapytuje stan EOF: Załóżmy, że masz ciąg znaków i chcesz sprawdzić, czy reprezentuje on liczba całkowita w całości, bez dodatkowych bitów na końcu, z wyjątkiem białych znaków. Używając C++ iostreams, wygląda to tak:

  std::string input = "   123   ";   // example
  
  std::istringstream iss(input);
  int value;
  if (iss >> value >> std::ws && iss.get() == EOF) {
      consume(value);
  } else {
      // error, "input" is not parsable as an integer
  }
  

  Używamy dwóch wyników tutaj. Pierwszym z nich jest iss, sam obiekt stream, aby sprawdzić, czy sformatowana ekstrakcja do value powiodła się. Ale potem, po zużyciu również whitespace, wykonujemy kolejną operację we / wy / iss.get() i spodziewamy się, że zakończy się ona niepowodzeniem jako EOF, co ma miejsce, jeśli cały łańcuch został już zużyty przez sformatowaną ekstrakcję.

  W C biblioteka standardowa możesz osiągnąć coś podobnego za pomocą funkcji strto*l, sprawdzając, czy wskaźnik końcowy osiągnął koniec łańcucha wejściowego.

Odpowiedź

while(!eof) jest źle, ponieważ testuje na coś, co jest nieistotne i nie testuje na coś, co musisz wiedzieć. W rezultacie błędnie wykonujesz kod, który zakłada, że uzyskuje dostęp do danych, które zostały pomyślnie odczytane, podczas gdy w rzeczywistości nigdy się to nie zdarzyło.