C++ vs D, Ada y Eiffel (horrible mensajes de error con plantillas)

El problema, en el fondo, es que la recuperación de errores es difícil, sea cual sea el contexto.

Y cuando se tienen en cuenta gramáticas horribles de C y C++, solo se puede preguntar que los mensajes de error no son peores que eso! Me temo que la gramática C ha sido diseñada por personas que no tenían ni idea de las propiedades esenciales de una gramática, una de ellas es que cuanto menos confianza en el contexto, mejor y la otra es que debe esforzarse para que sea tan inequívoca como posible.

Ilustremos un error común: olvidar un punto y coma.

struct CType {
  int a;
  char b;
}
foo
bar() { /**/ }

Bien, esto está mal, ¿dónde debería ir el punto y coma que falta ? Bueno, desafortunadamente es ambiguo, puede ir antes o después foo porque:

• C considera normal declarar una variable en zancada después de definir un struct
• C considera normal no especificar un tipo de retorno para una función (en cuyo caso el valor predeterminado es int)

Si razonamos acerca de, podríamos ver que:

• si foo nombra un tipo, entonces pertenece a la declaración de función
• si no, probablemente denota una variable... a menos que, por supuesto, hayamos hecho un error tipográfico y estuviera destinado a ser escrito fool, que resulta ser un tipo: /

Como puede ver, la recuperación de errores es francamente difícil, porque necesitamos inferir lo que el escritor quiso decir, y la gramática está lejos de ser receptiva. Sin embargo, no es imposible, y la mayoría de los errores pueden ser diagnosticado más o menos correctamente, e incluso recuperado de... solo toma considerable esfuerzo.

Parece que las personas que trabajan en gcc están más interesadas en producir código rápido (y quiero decir rápido, buscar los últimos puntos de referencia en gcc 4.6) y agregar características interesantes (gcc ya implementa la mayoría, si no todo, de C++0x) que producir mensajes de error fáciles de leer. Puede culparlos ? No puedo.

Afortunadamente hay gente que piensa que un informe de errores preciso y una buena recuperación de errores son un objetivo muy valioso, y algunos de ellos han estado trabajando en CLang durante bastante tiempo, y continúan haciéndolo.

Algunas características agradables, de la parte superior de mi cabeza:

• Mensajes de error concisos pero completos, que incluyen los rangos de origen para exponer exactamente de dónde emanó el error
• Fix-It señala cuando es obvio lo que se quería decir
• , En cuyo caso el compilador analiza el resto del archivo como si la solución ya hubiera estado allí, en lugar de arrojar líneas sobre líneas de galimatías
• (reciente) evite incluir la pila include para notas, para cortar en el cruft
• (reciente) tratando solo de exponer los tipos de parámetros de plantilla que el desarrollador realmente escribió, y preservando typedefs (hablando así de std::vector<Name> en lugar de std::vector<std::basic_string<char, std::allocator<char>>, std::allocator<std::basic_string<char, std::allocator<char>> > lo que hace toda la diferencia)
• (reciente) recuperándose correctamente en caso de que falte template en caso de que falte en una llamada a una plantilla método desde dentro de otro método de plantilla

Pero cada uno de ellos ha requerido varias horas a días de trabajo.

Ciertamente no vinieron gratis.

Ahora, los conceptos deberían (normalmente) haber hecho nuestras vidas más fáciles. Sin embargo, en su mayoría no se habían ensayado, por lo que se consideró preferible eliminarlas del proyecto. Debo decir que me alegro de ello. Dada la relativa inercia de C++, es mejor no incluir características que no hayan sido completamente revisadas, y los mapas conceptuales no me emocionaron. Tampoco entusiasmaron a Bjarne o Herb, al parecer, ya que dijeron que reconsiderarían los conceptos desde cero para el siguiente estándar.