Libelektra: generación de código para errores

Personalmente, prefiero la opción 1. Los códigos de error deberían cambiar solo con muy poca frecuencia, lo que hace que el esfuerzo adicional de escribir manualmente el código C y mantener otros idiomas sincronizados sea insignificante. El esfuerzo inicial también debería ser menor en comparación con la configuración de cualquier forma de generación automática.

¿Por qué no la opción 2?

Las plantillas de bigote deben suministrarse con los datos de entrada de alguna manera. O tenemos que usar un ejecutable personalizado que se compila en el momento de la compilación. En ese caso, simplemente nos desharíamos del std::cout << ... en el código C ++, pero no cambiaría mucho más. La otra opción es usar el ejecutable de bigote predeterminado, que es un script de Ruby y, por lo tanto, requiere que Ruby esté instalado.

Además, kdb gen no se puede reutilizar, ya que eso requeriría compilar primero kdb , que necesita kdberrors.h .

¿Por qué no la opción 3?

La generación del código C puede funcionar en CMake, pero los lenguajes más complejos pueden tener problemas con el uso de CMake.

Si decidimos utilizar alguna forma de generación de código, solo deberíamos generar las partes que es absolutamente necesario generar. Por ejemplo, el actual kdberrors.h contiene una gran cantidad de código que es completamente estático e independiente de los errores que tengamos. Este código no debería generarse, deberíamos #include desde un archivo estático.

También prefiero la opción 1 debido a los códigos de error estables. Agregar la generación de código también agrega una complejidad innecesaria al código general, que nuevamente es propenso a errores.

@kodebach gracias por su elaboración de la opción 2

Creo que está bastante claro que optamos por la opción 1, @Piankero ,

Para las fijaciones significa que no hay muchos cambios.

¿Qué sería genial si tuviéramos un tutorial de escritura vinculante que describa:

1. qué partes de los enlaces de Elektra tienen sentido (aplicación, complemento, herramientas, ...)
2. cómo integrar enlaces en CMake (si es posible y útil)
3. qué partes de las vinculaciones pueden y deben diferir para cada idioma. Esto incluye:
   
   
   
   • iteradores
   
   
   • conversión a tipos nativos (strings, int, ...)
   
   
   • sobrecarga del operador (si está disponible)
   
   
   • otras integraciones de lenguajes de programación (flujos, códigos hash, identidad, ...)
   
   
   • devolvió errores de las funciones kdb (de qué trata este problema aquí)
   
   

Espero que podamos ampliar este tutorial para las diferentes situaciones que vemos en diferentes idiomas. @Piankero , ¿puede comenzar a escribir el tutorial, en particular la sección de manejo de errores (cómo implementar la herencia, ...)

Tutorial: # 2875
Decisión de diseño: # 2872