現在、 network.h
は、プラットフォーム固有のヘッダーが多数含まれています( u.h
、 windows.h
、 unistd.h
)。 これらを1つのファイル(またはいくつかのファイル)に限定する必要があります。
ネットワーク用のOS機能と、単調クロック用のOS機能に薄い抽象化を作成することをお勧めします。 次に、プラットフォームの種類ごとに1つのファイル(たとえば、 ${module}_win32.c
、 _unix.c
、 _osx.c
、 _posix.c
、...)を作成し、プリプロセッサに従って条件付きでコンパイルします。すでに行っているように、シンボル。 欠点は、宣言のオーバーヘッドが少し増えることです。現在、これらの#ifdef
は関数内にあり、プラットフォームごとに再定義する必要があるためです。 利点は、コード自体に#ifdef
がまったくないか、ほとんどないことです。プラットフォーム固有のコードは、プラットフォームの抽象化と1100行のファイルを混合するのではなく、小さなファイルのセットに含まれます。アプリケーションコード。
いいですね
「Windowsシステム」と「posixシステム」と「テストシステム」で実装できる「システム」インターフェースを作ってみませんか? テストシステムは単体テストで使用でき、実際にシステムコールを実行せずにシステムをシミュレートします。
私は実装の提案に同意しません。 プラットフォームごとに異なる方法で記述する必要のある関数をラップするために#ifdef
使用して、すべての関数を1つのファイル{network,time,...}.c
に収めたいと思います。
個別のファイルに対するこのメソッドの利点は、すべてのプラットフォーム固有のコードを静的関数として強制し、より高いレベルのtoxcoreに対して単一のAPIを公開できることです。 プラットフォーム実装の詳細は、単一のファイルから簡単に表示できます。 プラットフォームの特性により、複数のファイルにまたがるのではなく、単一のファイル内で抽象化と処理が必要になります。 また、cmakelists.txtファイルの保守が容易になります(すでに私たちから離れ始めています)。その後、現在のレビューシステムでレビューします。
完全には修正されていません
@GrayHatterは同意しました。 OSの詳細を実装する単一のファイルを作成しましょう。
今のところ@Diadloの割り当てを
最も参考になるコメント
「Windowsシステム」と「posixシステム」と「テストシステム」で実装できる「システム」インターフェースを作ってみませんか? テストシステムは単体テストで使用でき、実際にシステムコールを実行せずにシステムをシミュレートします。