Libelektra: geração de código para erros

Pessoalmente, prefiro a opção 1. Os códigos de erro devem mudar muito raramente, o que torna o esforço adicional de escrever manualmente o código C e manter outras linguagens em sincronia insignificante. O esforço inicial também deve ser menor em comparação com a configuração de qualquer forma de geração automática.

Por que não a opção 2?

Os modelos Mustache devem ser fornecidos com os dados de entrada de alguma forma. Ou temos que usar um executável personalizado que é compilado em tempo de construção. Nesse caso, apenas nos livraríamos do std::cout << ... no código C ++, mas nada mais mudaria. A outra opção é usar o executável bigode padrão, que é um script Ruby e, portanto, requer a instalação do Ruby.

Além disso, kdb gen não pode ser reutilizado, pois isso exigiria a compilação de kdb primeiro, que precisa de kdberrors.h .

Por que não a opção 3?

Gerar o código C pode funcionar no CMake, mas linguagens mais complexas podem ter problemas com o uso do CMake.

Se decidirmos usar alguma forma de geração de código, devemos gerar apenas as partes que absolutamente precisam ser geradas. Por exemplo, o kdberrors.h atual contém uma grande quantidade de código que é completamente estático e independente de quais erros realmente temos. Este código não deve ser gerado, devemos #include it a partir de um arquivo estático.

Também prefiro a opção 1 por causa dos códigos de erro estáveis. Adicionar geração de código também adiciona complexidade desnecessária ao código geral, que é novamente sujeito a erros.

@kodebach, obrigado por sua elaboração na opção 2

Acho que está bem claro que vamos para a opção 1, @Piankero você pode escrever a decisão?

Para as ligações, isso significa que não muda muita coisa.

O que seria ótimo se tivéssemos um tutorial de escrita de ligação, descrevendo:

1. quais partes das ligações Elektra fazem sentido (aplicativo, plug-in, ferramentas, ...)
2. como integrar ligações no CMake (se possível e útil)
3. quais partes das ligações podem e devem ser diferentes para cada idioma. Isso inclui:
   
   
   
   • iteradores
   
   
   • conversão para tipos nativos (strings, int, ...)
   
   
   • sobrecarga do operador (se disponível)
   
   
   • outras integrações de linguagem de programação (streams, hash-codes, identidade, ...)
   
   
   • retornou erros de funções kdb (sobre o que se trata este problema aqui)
   
   

Espero que possamos estender este tutorial para as diferentes situações que vemos em diferentes idiomas. @Piankero, você pode começar a escrever o tutorial, em particular a seção de tratamento de erros (como implementar herança, ...)

Tutorial: # 2875
Decisão de Projeto: # 2872