Чому iostream :: eof всередині циклу (тобто `while (! Stream.eof ())`) вважається неправильним?

Щойно я знайшов коментар у цій відповіді, в якому говорилося, що використовувати iostream::eofв циклі стан "майже напевно неправильно". Я, як правило, використовую щось на кшталт while(cin>>n)- яке, мабуть, неявно перевіряє на EOF.

Чому перевірка eof явно використовує while (!cin.eof())неправильно?

Чим він відрізняється від використання scanf("...",...)!=EOFв C (яким я часто користуюся без проблем)?

Тому що 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
}    

( Дякую Тоні Д за пропозицію підкреслити відповідь. Дивіться його коментар нижче для прикладу, чому це більш надійно. )

Основний аргумент проти використання, 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()підтверджується, що поки є що читати, це правильне. Його мета - не простий термінатор, а цикл.

Поки що добре, але що станеться, якщо в потоці є простір - що звучить як головне занепокоєння 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) { ... }.