¿Por qué iostream :: eof dentro de una condición de bucle (es decir, `while (! Stream.eof ())`) se considera incorrecto?

Acabo de encontrar un comentario en esta respuesta que dice que usar iostream::eofen una condición de bucle es "casi seguro que está mal". Generalmente uso algo como while(cin>>n), que supongo que comprueba implícitamente EOF.

¿Por qué es while (!cin.eof())incorrecto verificar eof explícitamente ?

¿Cómo es diferente de usar scanf("...",...)!=EOFen C (que a menudo uso sin problemas)?

Porque iostream::eofsolo regresará true después de leer el final de la transmisión. No , no indican, que la siguiente lectura será el final de la secuencia.

Considere esto (y suponga que la próxima lectura será al final de la secuencia):

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
}

Contra esto:

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

Y en su segunda pregunta: porque

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

es lo mismo que

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

y no es lo mismo que

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

Parte superior de la línea inferior: con el manejo adecuado del espacio en blanco, lo siguiente es cómo eofse puede usar (e incluso, ser más confiable que fail()para la verificación de errores):

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

( Gracias Tony D por la sugerencia de resaltar la respuesta. Vea su comentario a continuación para ver un ejemplo de por qué esto es más robusto ) .

Al argumento principal en contra del uso eof()parece faltarle una sutileza importante sobre el papel del espacio en blanco. Mi propuesta es que, verificar eof()explícitamente no solo no es " siempre incorrecto ", lo que parece ser una opinión primordial en este y otros hilos SO similares, sino que, con un manejo adecuado del espacio en blanco, proporciona un espacio más limpio y más confiable manejo de errores, y es la solución siempre correcta (aunque, no necesariamente la más estricta).

Para resumir lo que se sugiere como la terminación "correcta" y el orden de lectura es el siguiente:

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

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

La falla debida al intento de lectura más allá de eof se toma como la condición de terminación. Esto significa que no hay una manera fácil de distinguir entre una transmisión exitosa y una que realmente falla por otras razones que no sean eof. Tome las siguientes transmisiones:

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

while(in>>data)termina con un conjunto failbitpara las tres entradas. En el primero y tercero, eofbittambién se establece. Entonces, más allá del bucle, uno necesita una lógica extra muy fea para distinguir una entrada adecuada (primera) de las incorrectas (segunda y tercera).

Mientras que, tome lo siguiente:

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

Aquí, in.fail()verifica que mientras haya algo para leer, es el correcto. Su propósito no es un simple terminador while-loop.

Hasta ahora todo bien, pero ¿qué sucede si hay un espacio final en la secuencia? ¿Cuál parece ser la principal preocupación contra el eof()terminador?

No necesitamos entregar nuestro manejo de errores; solo come el espacio en blanco:

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::wsomite cualquier espacio final potencial (cero o más) en la secuencia al configurar eofbity no elfailbit . Por lo tanto, in.fail()funciona según lo esperado, siempre que haya al menos un dato para leer. Si las secuencias en blanco también son aceptables, entonces la forma correcta es:

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
}

Resumen: Una construcción adecuada while(!eof)no solo es posible y no está mal, sino que permite que los datos se localicen dentro del alcance y proporciona una separación más clara de la verificación de errores de la empresa como de costumbre. Dicho esto, while(!fail)es indiscutiblemente un lenguaje más común y conciso, y puede preferirse en escenarios simples (datos únicos por tipo de lectura).

Porque si los programadores no escriben while(stream >> n), posiblemente escriban esto:

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

Aquí el problema es que no puede hacerlo some work on nsin verificar primero si la lectura de la transmisión fue exitosa, porque si no tuvo éxito, some work on nproduciría un resultado no deseado.

El punto es que, eofbit, badbit, o failbitse establece después de que se hizo un intento de leer de la corriente. Entonces, si stream >> nfalla, entonces eofbit, badbito failbitse establece de inmediato, por lo que es más idiomático si escribe while (stream >> n), porque el objeto devuelto se streamconvierte en falsesi hubo algún error en la lectura de la secuencia y, en consecuencia, el ciclo se detiene. Y se convierte en truesi la lectura fue exitosa y el ciclo continúa.

Las otras respuestas han explicado por qué la lógica es incorrecta while (!stream.eof())y cómo solucionarlo. Quiero centrarme en algo diferente:

¿Por qué es iostream::eofincorrecto verificar eof explícitamente ?

En términos generales, verificar eof solo es incorrecto porque la extracción de flujo ( >>) puede fallar sin llegar al final del archivo. Si tiene, por ejemplo, int n; cin >> n;y la secuencia contiene hello, entonces hno es un dígito válido, por lo que la extracción fallará sin llegar al final de la entrada.

Este problema, combinado con el error lógico general de verificar el estado del flujo antes de intentar leerlo, lo que significa que para N elementos de entrada el ciclo se ejecutará N + 1 veces, conduce a los siguientes síntomas:

• Si la secuencia está vacía, el ciclo se ejecutará una vez. >>fallará (no hay entrada para leer) y todas las variables que se suponía que debían establecerse (por stream >> x) en realidad no se inicializan. Esto lleva a que se procesen datos basura, que pueden manifestarse como resultados sin sentido (a menudo, cantidades enormes).

  (Si su biblioteca estándar se ajusta a C ++ 11, las cosas son un poco diferentes ahora: un error >>ahora establece variables numéricas en 0lugar de dejarlas sin inicializar (excepto para chars)).

• Si la secuencia no está vacía, el ciclo se ejecutará nuevamente después de la última entrada válida. Dado que en la última iteración todas las >>operaciones fallan, es probable que las variables conserven su valor de la iteración anterior. Esto puede manifestarse como "la última línea se imprime dos veces" o "el último registro de entrada se procesa dos veces".

  (Esto debería manifestarse un poco diferente desde C ++ 11 (ver arriba): ahora obtienes un "registro fantasma" de ceros en lugar de una última línea repetida).

• Si la secuencia contiene datos mal formados pero solo los verifica .eof, termina con un bucle infinito. >>no podrá extraer ningún dato de la transmisión, por lo que el bucle gira en su lugar sin llegar al final.

En resumen: La solución es poner a prueba el éxito de la >>operación en sí, no usar una separada .eof()método: while (stream >> n >> m) { ... }al igual que en C se prueba el éxito de la scanfmisma llamada: while (scanf("%d%d", &n, &m) == 2) { ... }.