Libelektra: エラーのコード生成

個人的には、オプション1を好みます。エラーコードはごくまれにしか変更されないため、Cコードを手動で記述し、他の言語の同期を維持するという追加の作業はごくわずかです。 また、初期の労力は、任意の形式の自動生成を設定する場合に比べて少なくする必要があります。

なぜオプション2ではないのですか？

口ひげテンプレートは、何らかの方法で入力データとともに提供する必要があります。 ビルド時にコンパイルされるカスタム実行可能ファイルを使用する必要があります。 その場合、C ++コードのstd::cout << ...を削除するだけですが、それ以外はほとんど変更されません。 もう1つのオプションは、デフォルトの口ひげ実行可能ファイルを使用することです。これはRubyスクリプトであるため、Rubyをインストールする必要があります。

また、 kdb genは再利用kdbコンパイルする必要があり、 kdberrors.hが必要になるためです。

なぜオプション3ではないのですか？

Cコードの生成はCMakeで機能する可能性がありますが、より複雑な言語ではCMakeの使用に問題がある可能性があります。

何らかの形式のコード生成を使用することにした場合は、絶対に生成する必要のある部分のみを生成する必要があります。 たとえば、現在のkdberrors.hは、完全に静的で、実際に発生するエラーに依存しない多くのコードが含まれています。 このコードは生成されるべきではありません。静的ファイルから#includeする必要があります。

エラーコードが安定しているので、オプション1も好みます。 コード生成を追加すると、コード全体が不必要に複雑になり、エラーが発生しやすくなります。

@kodebachオプション2について詳しく説明して

オプション1を選択することは明らかだと思います。 @ Piankero決定を書いていただけますか？

バインディングの場合、それはあまり変更されないことを意味します。

拘束力のあるライティングチュートリアルがあり、次のことを説明しているとしたら、何が素晴らしいでしょう。

1. Elektraバインディングのどの部分が意味をなすか（アプリケーション、プラグイン、ツールなど）
2. バインディングをCMakeに統合する方法（可能で有用な場合）
3. バインディングのどの部分が言語ごとに異なる可能性があり、異なる必要があります。 これも：
   
   
   
   • イテレータ
   
   
   • ネイティブ型（strings、int、...）への変換
   
   
   • 演算子のオーバーロード（利用可能な場合）
   
   
   • 他のプログラミング言語の統合（ストリーム、ハッシュコード、アイデンティティなど）
   
   
   • kdb関数から返されたエラー（ここでのこの問題の内容）
   
   

このチュートリアルを、さまざまな言語で見られるさまざまな状況に拡張できることを願っています。 @Piankeroチュートリアル、特にエラー処理セクション（継承の実装方法など）の作成を開始してください。

チュートリアル：＃2875
設計上の決定：＃2872