0

私は非常に基本的なライブラリを構築しています。これは、必要に応じて他の人が使用できるようにリリースする予定の最初のプロジェクトです。そのため、組織に関する限り、いくつかの「ベストプラクティス」を知りたいと思います。私のプロジェクトの唯一のユニークな点は、プロジェクトで使用するために、ユーザーは特定の抽象クラスを拡張する必要があるということです。これが私の最初の質問につながります。

  • 私が見た多くのライブラリは、.a ファイルと単一の .h ファイルで構成されています。これはベストプラクティスですか？ユーザーが含めるファイルを選択できるように、すべてのパブリック .h ファイルを公開する方がよいのではないでしょうか? これが好ましい方法である場合、それはどのように正確に達成されますか? その単一の .h ファイルには何が入りますか?

2 つ目の質問は、依存関係に関するものです。たとえば、私の現在のプロジェクトは OpenGL、GLFW、および GLEW に依存しています。それらをプロジェクトで何らかの方法でパッケージ化する必要がありますか、それともユーザーの責任でそれらがインストールされていることを確認する必要がありますか?

編集:誰かが私のターゲット OS について尋ねました。私の依存関係はすべてクロスプラットフォームであるため、(おそらく素朴に) 私のライブラリもクロスプラットフォームにすることを望んでいます。

助けてくれてありがとう！

4

2 に答える 2

2

それは本当に状況に依存します。いくつかのかなり複雑な機能があり、それらが密接に関連する多数の機能にある場合、1 つのヘッダーが適切なソリューションです。

たとえば、画面に何かを描画する一連の関数を記述し、環境を構成/セットアップするためのいくつかの関数、シーン内のオブジェクトを定義および配置するためのいくつかの関数、実際の描画/処理を行うためのいくつかの関数が必要です。 、そして最後に分解し、1 つのヘッダー ファイルを使用するのが適切な計画です。

上記の場合、いくつかの小さなヘッダー ファイルを含む 1 つの「全体的な」ヘッダー ファイルを持つこともできます。特に、かなり大きなクラスがある場合、それらすべてを 1 つのファイルにまとめるとかなり面倒になります。

一方、液体に溶解したガスを処理する関数のセットが 1 つある場合、スチール ビームの強度/耐荷重を計算する関数の別のセット、ゴム タイヤの摩擦を計算する関数の別のセットがあります。 「物理/力学ライブラリ」に入れることがすべて実行可能な機能であっても、おそらく異なるヘッダーを持つ必要があります。

ライブラリにサードパーティのライブラリを提供することは、めったに良い考えではありません。はい、2 つのダウンロードを提供したい場合、1 つは「必要なものはすべて水を追加するだけ」で、もう 1 つは「裸のライブラリ」で、それで問題ありません。しかし、あなたのライブラリをダウンロードするのに必要以上に 3 倍の時間を費やしたくありません。単に、あなたのコードが使用している他の 3 つのライブラリが含まれているからです。これらのライブラリは既に私のマシン上にあります。ただし、必要なライブラリと、サポートされているプラ​​ットフォーム (およびサポートされているプラ​​ットフォーム) にそれらをインストールするために必要なことを文書化してください。また、テストしたライブラリのバージョン - 「最新のものを入手する」ことほど悪いことはありません。必要なバージョンが 2 歩前のものであることがわかります...

(そして、Jason C が指摘しているように、ライセンスは他のすべてのライセンスと互換性がなければならないため、コードが依存するいくつかの異なるパッケージがあると、ライセンスは非常に面倒になります。時にはそれが不可能な場合もあります...)

于 2013-08-04T18:23:12.017 に答える
1

オプションはありますが、それは、ライブラリを使用する開発者にとってどれだけ便利にするかによって異なります。

ヘッダーに関しては、平均的な複雑さのライブラリの一般的な方法は、開発者が必要なものすべてを取得するために含めることができる単一のヘッダーを用意することです。良い方法は、複数のヘッダーがある場合、ライブラリと同じ名前の単一のヘッダーを作成し (必須ではありません。単に共通です)、個々のヘッダーすべてを #include することです。次に、単一ヘッダーと個別ヘッダーを配布します。そうすれば、ユーザーは #include ですべてを取得するか、必要に応じて個別のものを #include するかを選択できます。

たとえば、mylibrary.h では:

#ifndef MYLIBRARY_H
#define MYLIBRARY_H

#include <mylibrary/something.h>
#include <mylibrary/another.h>
#include <mylibrary/lastone.h>

#endif

開発者にそのオプションを提供したい場合は、個々のヘッダーをスタンドアロンで含めることができることを確認してください (つまり、必要なものすべてを #include する)。

依存関係については、それらがインストールされていることを確認するのはユーザーの責任にする必要があります。ユーザーはコードをコンパイルしてライブラリにリンクしているため、依存ライブラリにリンクすることもユーザーの責任です。ライブラリにサードパーティの依存関係をパッケージ化すると、多くのリスクが発生します。

  1. 既に依存関係がインストールされているユーザーのシステムを壊す。
  2. Mats Petersson の回答で述べたように、ユーザーは既に持っている依存関係をダウンロードする必要があります。
  3. サードパーティ ライブラリのライセンス権の侵害。

最善の方法は、必要な依存関係を明確に文書化することです。

このため、実際には標準的な「ベスト プラクティス」はありません。正気の練習は良い練習になるでしょう。

于 2013-08-04T18:22:47.243 に答える