¿Lees los errores de compilación C o C ++ después del primero?

Nunca entendí por qué los compiladores de C y C ++ intentan recuperarse de los errores y continuar analizando. Casi siempre, el primer error genera un flujo de errores falsos que desaparecerán tan pronto como se corrija el primero. Después de varios años de experiencia, simplemente dejé de mirar cualquier error, excepto el primero de cada archivo. Vuelvo a ejecutar el compilador y luego lo vuelvo a hacer hasta que no haya más errores. ¿Es una práctica común?

A veces los errores no están relacionados. Me resulta más fácil mirar una lista de errores y corregir la causa raíz de una serie de errores relacionados, luego corregir el siguiente error no relacionado. Si el proyecto es grande y lleva un tiempo construirlo, encuentro que trabajar de esta manera es menos frustrante que corregir el primer error, recompilar, repetir ...

Depende del tiempo de compilación . Por ejemplo, si sé que acabo de cambiar un encabezado maestro que desencadenará una reconstrucción de todo el proyecto, ciertamente echaré un vistazo más de cerca al resto de la pila de errores y veré si puedo solucionar algunos de ellos. Eso me da una mejor sensación cuando me pongo de pie para hacer café mientras se ejecuta el compilador.

Sí, hago lo mismo, a menos que esté usando el compilador para ayudarme a refactorizar, en cuyo caso me gusta la lista completa de errores :)

Si hay un hueco en los números de línea, el compilador probablemente se recupere y luego encontró otro error.

Por lo general, solo intenta corregir un error en cada grupo.

Los mejores compiladores producirán mejores resultados y le darán más errores útiles después del primero, a menudo a través de algún tipo de corrección automática de los errores para que al menos se pueda verificar un código presumiblemente bueno. Pero entonces, estoy acostumbrado a trabajar en Java, en Eclipse, donde los errores tipográficos de sintaxis se detectan instantáneamente y se corrigen fácilmente, y otros errores del compilador tienden a ser más diversos y más fáciles de recuperar para el compilador. Solo puedo suponer que es similar cuando trabajo en IDEs de Microsoft y otros en C ++ o C #.

Sí, o al menos los hojeo. Es bastante fácil averiguar si los errores están relacionados (por lo general, basta con mirar el número de línea) y me gusta arreglarlos todos de una sola vez y luego volver a compilarlos.

Hago esto (para leer los errores más allá del primero) solo si la compilación de 1 cpp es muy larga. O no disponible. Entonces prefiero asegurarme de que arreglé todo lo que pude identificar en los errores del compilador como ajeno al primer error.

Cuando su archivo cpp se puede compilar solo y lo hace en menos de un segundo (o si tiene errores de puntería "intellisense" incluso antes de que comience la compilación), no tiene que hacer esto la mayor parte del tiempo.

Actualmente trabajo en un proyecto donde no puedo compilar un cpp solo (y no tengo la mano en el sistema de compilación, así que no puedo cambiar ese O__o) y algunos archivos cpp pueden tardar más de diez minutos en compilarse ( incluso después de mucho esfuerzo para reducir eso, solo lo reducimos al 50% del tiempo de compilación original ...).

En este tipo de configuración de compilación muy larga, tiende a pensar mucho antes de presionar "compilar" ... e incluso a pensar mucho después, tal vez para encontrar errores antes del compilador, ya que ciertamente es más rápido para obtenerlos mentalmente que .

Es bastante común hacer lo que haces. Por lo general, les digo a los pasantes o programadores novatos abrumados por la cantidad de errores que ignoren casi todos los errores, excepto el primero. Es muy probable que se deba corregir un error real, y no un error fantasma engañoso causado por uno anterior. Algunos compiladores (¿la mayoría?) Tienen la opción de dejar de compilar después del primer error por este motivo. Los sistemas de compilación generalmente se pueden configurar para detenerse después del primer archivo que también tiene errores.

Sin embargo, hay razones para continuar compilando después de detectar errores también. Por ejemplo, es posible que desee contar cuántos archivos tienen errores o para ver si un archivo de encabezado incluido causa errores en más de un archivo.