アノテーションを使用したC / C ++でのモジュラーアプリケーションの開発

最初の記事では、プリプロセッサを使用して、C / C ++のソースレベルでモジュール性を整理することについて説明しました。 つまり、このメソッドは、ソース内に特定のメタデータを書き込むことに要約されます。これは、外部ツールによって分析され、モジュール化を実装できるグルーソースを生成するために使用されます。 実装の詳細は前述の記事に記載されているため、ここでは繰り返しません。 この記事では、もう少し先に進み、メタデータまたは注釈を使用して、モジュール性だけでなく他の便利な機能も実装できることを示します。 Google GuiceやSpring for C（モジュール性とアスペクトに関連する部分）のようなものでなければなりません。 この記事は最初の記事への追加と改善であると別に強調するため、ここでは実装の技術的な詳細についてではなく、ユーザーにどのように見えるかについて説明します。 このトピックに興味がある場合は、コンフィギュレーターアプリケーション自体が内部にどのように配置されているかを説明した続きを作成します。

ユニバーサルアノテーション

以前のアプローチは、ソース内にメタデータを書き込む方法として#pragmaディレクティブの使用に基づいていました。 このメタデータの形式は任意に選択され、特定のアプリケーション（ソースと関連付けられている抽象モジュールとの関係の説明）に合わせて調整されています。 実際、注釈の概念はやや広範です。 特に、JavaやC＃などの言語と類似点を描くことができます。アノテーションでは、アノテーションが含まれるコードに関する任意のステートメントを記述できるため、何らかの汎用形式を使用すると便利です。

このアプローチの既存の実装の例として、ファイル内のさまざまな変数をXMLとして記述できるKeil構成ウィザード （たとえば、定数、配列のサイズなど）を挙げることができます。 次に、エディターで、構成タブに移動し、これらのオプションをファイル内で検索するのではなく、グラフィカル形式で構成できます。 さらに、ソースコードには、アノテーションと呼ばれる可能性のある他の情報が多くあります（たとえば、GCCの__attribute__内に記述されているもの、あらゆる種類の__declspecなど）。

いくつかの理由により、コメントに注釈を書くことを拒否することが決定されました。なぜなら、後者は、私の深い信念において、常に1つの機能のみを実行する必要があるからです。 ご存知のように、「ソフトウェアの非常に複雑なことは、1つのことで2つのことをすることです」 一方、 ＃pragmaの使用にも問題があります。不明な#pragmaは、プロジェクト内の多数のファイルではあまり見栄えが良くないという警告を引き起こします（各ファイルにいくつかの警告があります）。 これを回避するために、コンパイル時に空で表示されるマクロで注釈をラップすることが決定されました。 一部のコンパイラが突然内部のニーズに合わせてこのような形式のサポートを開始し、 ＃pragmaが必要になった場合、C99標準は最終的にマクロを介して#pragmaを定義する機能を導入するため、この意味でのマクロはより普遍的なソリューションです。

2番目の質問は、マクロ内に記録された注釈自体の形式に関連していました。 ただし、近年では、これらのタスクのためにXMLがより普及しています。 上記のKeilの例に加えて、FreeRTOSプロジェクトでも使用されています（コメントでも）。 XMLは、審美的な理由からまだあまり良くないことを言わなければなりません。XMLはかなり冗長であるため、この形式の情報を扱うのはあまり便利ではありません。 同時に、人間が読み書きできるように機械可読なマークアップ言語があり、C構文とも互換性があります-これはJSONです。 ただし、引用符でキーを引用する必要があるため、コード内の注釈の外観があまり美しくないため、拡張バージョンのYAMLが使用されました。 YAMLのすべての機能のうち、引用符なしでキーを記述する機能のみが使用されることに注意してください。 注釈は、パーサーに渡される前に常に単一の行に変換されるため、行の折り返しに関連付けられたYAML機能は使用できません。 JSONはYAMLのサブセットであるため、すべてを純粋なJSONで記述することもできます。キーから引用符を省略する機能は、小さな素敵なボーナスと見なされるべきです。

したがって、一番下の行には次のものがあります。CソースにはマクロFX_METADATA（x） （1つの引数付き）を含めることができ、その中にJSON形式で注釈が書き込まれます。 注釈自体の中に閉じ括弧を使用する場合のエラーを避けるために、注釈は括弧で囲まれています。 慣例により、注釈は常にキーと値のペアのコレクションです。つまり、JSONの用語では、それらはハッシュです。 例：

FX_METADATA(( { annotation: "hello world!" } )) 

ご想像のとおり、最初の記事のプラグマは新しい形式に「翻訳」され、今では次のように記述されていました。

 #pragma fx interface MY_INTERFACE:MY_IMPLEMENTATION 

今では次のように書かれています：

 FX_METADATA(( { interface: [MY_INTERFACE, MY_IMPLEMENTATION] } )) 

モジュール性の実装に関しては、変更は純粋に表面的なものであり、偶然記録されていたものすべてが多かれ少なかれ普遍的な形式で記録され始めました。

#includeに関しては、すべてがほとんど変更されていません：マクロFX_INTERFACEはまだ引数として使用されていますが、現在は常に1つの引数があります-それは常に、特定のインターフェイスを指定する機能なしでデフォルトインターフェイスをオンにすることを意味します。

要約すると、ソースには、ソースが任意のモジュールに属しているかどうかを説明する注釈が含まれています。 モジュールは、1つのヘッダーファイル（インターフェイスを記述）と任意の数のソースファイル（* .c、* .cppなど）を含むソースのセットです。 ファイルのモジュールへの所属に関する情報は、コンパイルの前の段階で抽出されます。 その後、外部アプリケーションはヘッダーファイルの名前をモジュールの名前にマップするファイルを生成します。これにより、通常のように、ファイル名だけでなく、モジュールの観点から#includeが機能するようになります。 どのモジュールをシステムに含めるかを見つける方法があり、各ソースにはモジュールに属することに関する情報が含まれているため、コンパイルする必要があるすべてのファイルを自動的に見つけることができます。 つまり、いくつかのソースコード#include FX_INTERFACE（MY_MODULE）を記述すると、MY_MODULEインターフェイスに属することについてのラベルを含むすべてのソースがシステムに含まれることになります。

コンフィギュレーター

当然、 ランタイムが管理言語で行うことは、ここの誰かによっても行われるべきなので、これを実装するアプリケーションについて少しお話します。 アノテーションフレームワークは、クラスのセット（DLL）としてC＃で実装されます。 C＃で書く価値があるかどうかの問題は、今のところ舞台裏に残されています。 フレームワークは、メタデータの使用がアセンブリのみに制限されないように作成されました。 とりわけ、メタデータリポジトリへのアクセスを外部から取得できるように、インターフェイスを提供します。 これにより、メタデータに基づいて特定のアクションを実行できるサードパーティモジュールを作成できる可能性が広がります。 将来的には、すべてのプラグインはMEFを介して接続され、プロジェクト構造から切り離される予定です。

DLLのセットに加えて、コンフィギュレーターの機能を実装する2つのアプリケーション（コンソールとグラフィカル）もあります。 後者は非常にプロトタイプの状態であり、今は検討しませんが、コンソールについては簡単に検討します。

コンフィギュレーターには7つのコマンドラインキーがあり、そのうち3つのみが必須です。ソースフォルダー、ターゲットモジュール（依存関係の解決を開始するモジュール）、および出力ファイル/フォルダーへのパスのリストです。 たとえば、注釈付きソースがフォルダーc：\ src1およびd：\ src2にあり、モジュールMY_MODULEをビルドする必要がある場合、コマンドは次のようになります。

 fx_mgr -pc:\src1,d:\src2 -t MY_MODULE -o output_folder 

コマンドを実行すると、ソースからメタデータが抽出され、MY_MODULEモジュールから始まる依存関係が解決され、コンパイルする必要があるすべてのファイルが定義されます。その後、コンパイル用のファイルの出力が生成されます。

「出力」する方法は2つあります。

最初の方法

小さなプロジェクトに適しており、ソーステキストの形式で何かを配信するのにも便利です。 既存のフォルダーが引数として-oキーで指定された場合、この場合、必要なすべてのファイルが指定されたフォルダーにコピーされ、ヘッダーファイルはそれらが実装するインターフェイスの名前に従って名前が変更されます。 システムには各インターフェイスの実装を1つしか含めることができないため、コンパイル用のファイルを1つのフォルダーにフラット形式で配置しても名前の競合は発生せず、マクロFX_INTERFACE （引数#include ）は非常に簡単に定義できます：

 #define FX_INTERFACE(i) <ih> 

追加のファイルは必要ありません。 組み込みでは、特定のコンパイラキーでコンパイルする必要があるため、ソースの形式で提供されるライブラリを使用する必要が非常に多くあります。 このフラットファイルアプローチにより、makeの使用やIDEなどへのファイルの追加が簡単になります。

第二の方法

もちろん、毎回アセンブリ中に何かをコピーするのは悪いオプションなので、別の方法があります： -oキーで指定されたものがフォルダーでない場合、指定された名前の新しいファイルが作成され（または既存のファイルが上書きされます）コンパイルされるファイルへの絶対パスのリストが配置されます。 その後、このファイルをビルドシステム（makeまたはMSBuildを含む）で使用して、ファイルをコンパイルできます。 これは、ファイルに注釈が含まれ、使用モジュールが含まれている場合、FX_INTERFACE / FX_METADATAマクロはどこから来たのかという疑問を招きます。 本当にどこからでも。 それらを取得するには、 -hスイッチを使用します。 指定されている場合、いわゆる 共通ヘッダーファイル。ファイル名からモジュール名へのマッピング、およびFX_INTERFACEおよびFX_METADATAの定義を含むファイル。 このタイプのアセンブリを使用する場合、すべてのコンパイル済みファイルにコンパイラディレクティブによってこのファイルを強制的に含める必要があります。
これらはすべて、以前に実装された基本であり、ユニバーサルアノテーションなしで#pragmaで完全に機能しました。次に、依存関係の実装について簡単に説明し、構造化メタデータを既に必要とする問題に進みます。

依存性注入

同じインターフェースの複数の実装をサポートする必要性について、いくつかの言葉を述べる価値があります。 最初は、フレームワーク全体がRTOSの構成システムから発展しました。RTOSは、アプリケーションの要件に理想的に適合する必要があります。 完璧であるため、各インターフェースの単一の実装ではもはや十分ではありません。 OS自体は単一のエンティティとして存在せず、小さなブロックから構築されました。 この場合、いくつかのモジュールの実装が行われ、それぞれが特定の要件に対して「シャープ化」されました。 次に、すべての実装のインターフェースが同じであるため、アプリケーションの各インターフェースに理想的な実装を選択することができました。 つまり、これはソースレベルでのCの静的な依存性注入です。 プロジェクトツリーのソースには、実際に使用されるモジュールに関する情報は含まれていません;実装を指定せずに抽象インターフェイスをインポートします。 実際の実装は、この情報が記述されたファイルの形式で、システムアセンブリの段階でコンフィギュレーターに外部XMLでの外部XML言語での記述方法と同様に示されます（必要に応じて、このようなXMLの記述を妨げるものはありません）。 最後に、同じメタデータを使用して、コンフィギュレーターが使用する実装を決定できる追加機能を決定できます。

ソースに各インターフェースの実装が1つしか含まれていない場合、コンフィギュレーター自身が代替手段がないことを理解し、誰かがこのインターフェースをインポートした場合、指定されたインターフェースで使用可能なモジュールのみを自動的に使用します。 各インターフェイスに多くの実装がある場合、プロンプトが表示されない場合、コンフィギュレーターは表示される最初の実装を選択します（そして、コンソールで何が起こったかについての警告を表示します）。 システムのこの構成では、通常、使用するインターフェイスの実装がわかっているため、コンフィギュレーターにヒントを与えることができます。- a <ファイル名>スイッチを使用して与えられます 。 指定されたファイルには、INTERFACE = VERSIONという形式の行が含まれています。ここで、INTERFACEはインターフェースの名前であり、VERSIONは使用する実装の名前です。 これは最初の部分で説明したものにすべて近づいており、構文はわずかに単純化されているだけなので、技術的な詳細についてはソースを参照することをお勧めします。

アスペクト

それが、私たちが最も興味深いことに到達した場所です。そのためにすべてが始まりました。 プログラミングにはさまざまな側面の定義がありますので、1つの短いメモで広大さを受け入れようとはしません。 アスペクトは、プロジェクトに含まれるモジュールに応じて組み立てる必要があるものの一部です。 たとえば、一部のオブジェクトに複数のタイプがある場合、これらのすべてのタイプを含む列挙型が必要な場合があり、新しいタイプ（プロジェクトにファイルを含めるだけ）を追加すると、この列挙型が自動的に展開されます。 このプロジェクトなどに含まれるいくつかのモジュールの数を調べる必要があるかもしれません。

明らかに、プリプロセッサとコードのトリックはこれを達成できません。 この特定のプロジェクトの一部であるモジュールに関する情報は、コンパイラーでも利用できません。 おそらく、背景から始めた方がいいでしょう。OSの要件の中には、システムコールテーブルをOSで利用可能なサービスのセットに調整する能力がありました。一方、モジュールにアセンブリが含まれ、ユーザーモードに機能がエクスポートされた場合、システムコールテーブルはこれを考慮に入れることでした。 これはニュースではありません。一部のオペレーティングシステム（NuttXなど）で同様の方法が使用されていますが、原則として、これはすべてプリプロセッサで実行されます。 モジュールが含まれている場合、 ＃defineが定義され、定義されている場合、 ＃ ifdefが機能し、このモジュールの機能がテーブル内にリストされます。 したがって、テーブル自体は#ifdefsで構成されます。 困難なサポートに加えて、このアプローチには、新しいモジュールが表示される場合、それに対応する機能をこのテーブルに手動で追加する必要があるという問題もあるため、テーブルにはシステムに表示できるすべての情報が含まれています。 アスペクトは問題を解決するように設計されています。プロジェクトに何かを追加する場合、さまざまな場所で多くの小さな編集を行う必要があります。列挙型の展開、ビルドシステムの構成へのエントリの追加など。

提案されたコンフィギュレータは、異なるアプローチを実装しています。 モジュールがあるので、コンフィギュレーター自体によって生成されたモジュールの一部を作成してみませんか？ 結局、依存関係の実装が実行された後、彼はシステムの構造とすべてのモジュールのメタデータの知識を持っています。

ソースには、注釈の特別なキーとして、「値のキー配列」という形式のペアのセットが含まれています。 コンフィギュレーターがすべての依存関係を解決すると、この構成に含まれるモジュールが認識されます。 さらに、これらすべてのモジュールはアスペクトキーの存在について検査され、見つかった場合は、キーの名前で#defineが作成され、すべての値が（システム内のすべてのモジュールから）リストされます。 つまり、モジュールの1つに、たとえば次のようなエントリが含まれている場合：

 FX_METADATA(({ aspects: [ { key: [ val1, val2, val3 ] } ] })) 

そして、次のような別の：

 FX_METADATA(({ aspects: [ { key: [ val4, val5, val6 ] } ] })) 

それは生成されます#define of the form

 #define key val1 val2 val3 val4 val5 val6 

すべての値（キーと値の両方）はテキストとして扱われるため、たとえば次のように記述できます。

 FX_METADATA(({ aspects: [ { key: [ "val1," , "val2," , "val3," ] } ] })) 

そして、＃define内の値はコンマで区切られます。 さて、あなたはアイデアを得る。

この#defineはどこで生成されますか？ キー-e <ファイル名>としてコンフィギュレーターに示されるヘッダーファイル。 このキーが指定されている場合、コンフィギュレーターは生成されたインターフェースをメタデータストアに追加します。 このインターフェースはCFG_ASPECTSと呼ばれ、＃include FX_INTERFACE（CFG_ASPECTS）として含めることができ、すべてのモジュールのアスペクトが含まれています。 このようなインターフェイスが既に存在する場合（つまり、ユーザーが既に手動で作成しており、分析後にソースプールに含まれている場合）、何も生成されず、既存のモジュールが使用されることに注意することが重要です。

オプション

オプションは、このモジュールの構成定数を定義する外部#defineです。 ファイルの観点だけでなく、モジュールの観点でも、Keilの類推と類似しています。 その主な目的は、GUIを介してこれらのパラメーターを設定することであるため、コンソールアプリケーションでオプションを使用することは非常に困難です。 アスペクトと同様に、オプションは生成されたCFG_OPTIONSインターフェースによって表されます。これには、ソース内の対応する注釈として記述されたこのモジュール構成のすべてのオプションが含まれます。 コンソールアプリケーションは、オプションをデフォルト値に設定したファイルを生成しますが、グラフィカルアプリケーションではそれらを設定できます。

オプションを使用するモデルは次のように想定されていました：ユーザーはOSをソースのセットとして受け取り、コンフィギュレーターを起動し、これらのソースを分析して使用可能なオプションを表示し、ユーザーがニーズに合わせてオプションを構成し、コンフィギュレーターが同じCFG_OPTIONSファイルを生成します。 その後、ユーザーは必要な構成済みソースの完全なセットを取得します。 つまり、開発のコンテキストでは、それらは一般にほとんど役に立たないので、これを終了する価値があると思います。

制限事項

現在のバージョンでは、メタデータを抽出するための単純化されたモデルが使用されます-コメント（正規表現による）はファイルから単に除外され、インクルードとメタデータ（また正規表現による）を検索します。 98％のケースでは、このアプローチは問題なく機能しますが、マクロやインクルードファイルのオーバーライドなど、一部の複雑なケースでは機能しません。 この場合、本格的なメタデータプロバイダーを使用する必要があります。これは、各ファイルを（システムプリプロセッサーによって）前処理し、メタデータと含まれているファイルを、プリプロセッサーでのトリックの場合でも100％保証付きで抽出します。 しかし、もちろん、多数のファイルの場合、これはかなり遅くなります（数百のファイルのプロジェクトの場合は数秒かかりますが、デバッグするのはかなり退屈です）。

現在の実装では、メタデータの並列抽出がサポートされています：この操作は完全に並列化されているため、メタデータの抽出と解析は、スレッドプールに基づいて動作するParallel.ForEachループを使用して行われます。したがって、複数のプロセッサがある場合、この操作は大幅に加速されます。

また、IDEの使用には若干の困難があります。実際、キャッシュされたIDEは、現在のプロジェクトにあるすべてのファイルをコンパイルする必要があると想定しています。 提案されたアプローチでは、コンフィギュレーターはプロジェクトのフォルダーパスのリストに基づいて、どのファイルをコンパイルするかを決定します。そのため、IDEで入力ファイルを何らかの方法でフィルター処理できない場合（ビルド時に言うことができる何らかのプラグインを使用して必要であり、何をコンパイルする必要がないか）、そのようなIDEを使用することはやや問題があります。 私はIDEを自分で使用せず、Sublime TextまたはVisual Studio Codeをエディターとして使用し、アセンブリはコマンドラインから実行するように構成されています。 さらに、RTOSは特定の構成のソースという形で提供されるため、問題はありませんが、IDEなしでは生きられない人は失望するかもしれません。 実際、コンパイルの前に実行される追加のビルドフェーズが導入されます。これは構成フェーズであり、すべてのIDEがこのアプローチと互換性があるわけではありません。

おわりに

プレゼンテーション、注釈、側面、モジュール性の混乱をおaび申し上げます。これらは1つの投稿で受け入れ、完全に開示するのが非常に難しい個別のトピックなので、この投稿を完全なものではなく、議論の始まりと考えます。 記載されていることが興味深いと思われる場合は、次のステップに進み、使用例とコンフィギュレーターのソースを確認できます。 これらはすべてgithubで利用できます。 これですべてです。ご清聴ありがとうございました。