Защо iostream::eof вътре в условие за цикъл (т.е. `while (!stream.eof())`) се счита за грешно?

Тъй като iostream::eof ще върне true само след като прочете края на потока. Това не показва, че следващото четене ще бъде краят на потока.

Помислете за това (и приемете, че следващото четене ще бъде в края на потока):

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
}

Срещу това:

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

И по втория ви въпрос: Защото

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

е същото като

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

инесъщите като

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

Най-долу в горния ред: При правилно боравене с бяло пространство, следното е как eof може да се използва (и дори да бъде по-надежден от fail() за проверка на грешки):

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

(Благодаря на Tony D за предложението да подчертаем отговора. Вижте неговия коментар по-долу за пример защо това е по-стабилно.)

Основният аргумент срещу използването на eof() изглежда липсва важна тънкост за ролята на бялото пространство. Моето предложение е, че изричното отчитане на eof() не само не е „винаги грешно“ -- което изглежда е преобладаващо мнение в тази и подобни нишки на SO --, но с правилно боравене с бялото пространство, то осигурява по-чисто и по-надеждно обработване на грешки и е винаги правилното решение (въпреки че не непременно най-трясък).

За да обобщим това, което се предлага като "правилен" ред за прекратяване и четене, е следното:

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

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

Неуспехът поради опит за четене след eof се приема като условие за прекратяване. Това означава, че няма лесен начин да се направи разлика между успешен поток и такъв, който наистина се проваля по причини, различни от eof. Вземете следните потоци:

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

while(in>>data) завършва с набор failbit за всички три входа. В първия и третия също е зададено eofbit. Така че след цикъла се нуждаете от много грозна допълнителна логика, за да разграничите правилния вход (1-ви) от неправилните (2-ри и 3-ти).

Като има предвид, че вземете следното:

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

Тук in.fail() проверява, че стига да има нещо за четене, то е правилното. Целта му не е просто терминатор на цикъла while.

Дотук добре, но какво се случва, ако има завършващо пространство в потока -- какво звучи като основното безпокойство срещу eof() като терминатор?

Не е необходимо да се отказваме от нашата обработка на грешки; просто изяж бялото пространство:

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 пропуска всяко потенциално (нула или повече) завършващо пространство в потока, докато задава eofbit, а не failbit. И така, in.fail() работи според очакванията, стига да има поне една информация за четене. Ако изцяло празните потоци също са приемливи, тогава правилната форма е:

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
}

Обобщение: Правилно конструираният while(!eof) е не само възможен и не е грешен, но позволява данните да бъдат локализирани в рамките на обхвата и осигурява по-ясно отделяне на проверката за грешки от обичайния бизнес. Като се има предвид това, while(!fail) безспорно е по-разпространен и кратък идиом и може да бъде предпочитан в прости (едни данни за тип четене) сценарии.

Защото ако програмистите не пишат while(stream >> n), те вероятно пишат това:

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

Тук проблемът е, че не можете да направите some work on n без първо да проверите дали четенето на потока е било успешно, защото ако е било неуспешно, вашето some work on n ще доведе до нежелан резултат.

Целият въпрос е, че eofbit, badbit или failbit се задават след като е направен опит за четене от потока. Така че, ако stream >> n се провали, тогава eofbit, badbit или failbit се задават незабавно, така че по-идиоматично, ако напишете while (stream >> n), тъй като върнатият обект stream се преобразува в false, ако има някаква грешка при четене от потока и следователно цикълът спира. И се преобразува в true, ако четенето е било успешно и цикълът продължава.

Другите отговори обясниха защо логиката е грешна в while (!stream.eof()) и как да я поправите. Искам да обърна внимание на нещо различно:

защо проверката за eof изрично използва iostream::eof е грешна?

Най-общо казано, проверката за eof само е погрешна, тъй като извличането на поток (>>) може да се провали, без да достигне края на файла. Ако имате напр. int n; cin >> n; и потокът съдържа hello, тогава h не е валидна цифра, така че извличането ще се провали, без да се стигне до края на входа.

Този проблем, комбиниран с общата логическа грешка при проверка на състоянието на потока преди да се опита да чете от него, което означава, че за N входни елемента цикълът ще се изпълнява N+1 пъти, води до следните симптоми:

• Ако потокът е празен, цикълът ще се изпълни веднъж. >> ще се провали (няма вход за четене) и всички променливи, които е трябвало да бъдат зададени (от stream >> x), всъщност са неинициализирани. Това води до обработване на ненужни данни, което може да се прояви като безсмислени резултати (често огромни числа).

  (Ако вашата стандартна библиотека отговаря на C++11, сега нещата са малко по-различни: неуспешно >> сега задава числови променливи на 0 вместо да ги остави неинициализирани (с изключение на chars).)

• Ако потокът не е празен, цикълът ще стартира отново след последното валидно въвеждане. Тъй като в последната итерация всички >> операции са неуспешни, променливите вероятно ще запазят стойността си от предишната итерация. Това може да се прояви като „последният ред се отпечатва два пъти“ или „последният въведен запис се обработва два пъти“.

  (Това трябва да се прояви малко по-различно от C++11 (вижте по-горе): Сега получавате "фантомен запис" от нули вместо повторен последен ред.)

• Ако потокът съдържа неправилно формирани данни, но вие проверявате само за .eof, ще получите безкраен цикъл. >> няма да успее да извлече никакви данни от потока, така че цикълът се върти на място, без изобщо да стигне до края.

За да обобщим: Решението е да тествате успеха на самата операция >>, а не да използвате отделен метод .eof(): while (stream >> n >> m) { ... }, точно както в C тествате успеха на самото извикване scanf: while (scanf("%d%d", &n, &m) == 2) { ... }.

Iostream::eof в цикъл се счита за грешен, защото не сме достигнали EOF. Така че това не означава, че следващото четене ще успее.

Ще обясня твърдението си с два примерни кода, които определено ще ви помогнат да разберете концепцията по-добре. Да кажем, когато искаме да прочетем файл с помощта на файлови потоци в C++. И когато използваме цикъл за запис във файл, ако проверим края на файла с помощта на stream.eof(), ние всъщност проверяваме дали файлът е достигнал края или не.

Примерен код

#include<iostream>
#include<fstream>
using namespace std;
int main() {
   ifstream myFile("myfile.txt");
   string x;
   while(!myFile.eof()) {
      myFile >> x;
     // Need to check again if x is valid or eof
     if(x) {
        // Do something with x
     }
   }
}

Когато използваме потока директно в цикъл, няма да проверяваме отново условието.

Примерен код

#include<iostream>
#include<fstream>
using namespace std;
int main() {
   ifstream myFile("myfile.txt");
   string x;
   while(myFile >> x) {
      // Do something with x
      // No checks needed!
   }
}