Libelektra: генерация кода для ошибок

Лично я предпочитаю вариант 1. Коды ошибок должны меняться очень редко, поэтому дополнительные усилия по написанию кода C вручную и поддержанию синхронизации других языков незначительны. Первоначальные усилия также должны быть меньше по сравнению с настройкой любой формы автоматической генерации.

Почему не вариант 2?

Шаблоны усов нужно как-то снабжать входными данными. Либо мы должны использовать настраиваемый исполняемый файл, который компилируется во время сборки. В этом случае мы бы просто избавились от std::cout << ... в коде C ++, но больше ничего не изменилось бы. Другой вариант - использовать исполняемый файл усов по умолчанию, который является сценарием Ruby и поэтому требует установки Ruby.

Также kdb gen нельзя использовать повторно, так как для этого сначала потребуется скомпилировать kdb , а для этого потребуется kdberrors.h .

Почему не вариант 3?

Создание кода C может работать в CMake, но более сложные языки могут иметь проблемы с использованием CMake.

Если мы все же решим использовать какую-либо форму генерации кода, мы должны генерировать только те части, которые абсолютно необходимо сгенерировать. Например, текущий kdberrors.h содержит много кода, который полностью статичен и не зависит от того, какие ошибки у нас действительно есть. Этот код не должен генерироваться, мы должны #include его из статического файла.

Я также предпочитаю вариант 1 из-за стабильных кодов ошибок. Добавление генерации кода также добавляет ненужной сложности к общему коду, который снова подвержен ошибкам.

@kodebach благодарим вас за подробное

Я думаю, что совершенно очевидно, что мы выбираем вариант 1, @Piankero, не могли бы вы написать решение?

Для привязок это означает, что мало что изменилось.

Что было бы замечательно, если бы у нас был учебник по написанию привязки, описывающий:

1. какие части привязок Elektra имеют смысл (приложение, плагин, инструменты, ...)
2. как интегрировать привязки в CMake (если возможно и полезно)
3. какие части привязок могут и должны различаться для каждого языка. Это включает:
   
   
   
   • итераторы
   
   
   • преобразование в собственные типы (строки, int, ...)
   
   
   • перегрузка оператора (если есть)
   
   
   • другие интеграции языков программирования (потоки, хэш-коды, идентификация, ...)
   
   
   • вернул ошибки из функций kdb (о чем здесь эта проблема)
   
   

Я надеюсь, что мы сможем расширить это руководство для различных ситуаций, которые мы видим на разных языках. @Piankero, не могли бы вы начать писать учебник, в частности раздел обработки ошибок (как реализовать наследование, ...)

Учебник: # 2875
Решение дизайна: # 2872