3

私は C++ クラスのコレクションを開発しており、コレクションのユーザーのコンパイルの容易さを損なうことなく、組織を維持する方法でコードを共有する方法に苦労しています。

私が見たオプションは次のとおりです。

  • コンパイル済みのライブラリ ファイルを配布する
  • ソースをヘッダーファイルに入れます（この回答で説明されているように暗黙のインラインを使用）
  • シンボリック リンクを使用して、コンパイラがファイルを検索できるようにします。

私は現在、3 番目のオプションを使用しています。ここでは、含めたいクラスごとに、各クラスのヘッダーとソース ファイルをシンボリック リンクします (例ln -s <path_to_class folder>/myclass.cpp) プロジェクト フォルダーの場所を移動できないことを除いて、これはうまく機能します (すべてのシンボリック リンクが壊れます)。 ) そして、シンボリックリンクされたすべてのファイルをぶら下げなければなりません。

私は 2 番目のオプション (Java の外観) を気に入っていますが、すべてをインラインで宣言するとコード サイズが肥大化するのではないかと心配です。

コレクションのユーザーは、どこかにプロジェクト フォルダーを作成し、何らかの形でコレクションをコンパイル プロセスに含めます。

いくつかのことが可能になることを望みます：

  1. 簡単なコンパイル (gcc *.cppプロジェクト フォルダーからのようなもの)
  2. コンパイルされていない形式でライブラリを簡単に配布できます。
  3. モジュールごとのライブラリ編成。
  4. コンパイルされたコードのサイズは肥大化していません。

ドキュメンテーション (Doxygen が処理します) やコンパイル時間については心配していません。全体のモジュールは小さく、最も遅いマシン上の最大のプロジェクトでさえ、コンパイルに数秒しかかかりません。

違いがある場合は、GCCコンパイラを使用しています。

4

3 に答える 3

0

すべてのコードにインライン ヘッダーを使用することになりました。ここでライブラリを見ることができます：

https://github.com/libpropeller/libpropeller/tree/master/libpropeller

ライブラリは次のように構成されています。

  • ライブラリ フォルダ
    • クラスA
      • classA.h
      • classA.test.h
    • クラスB
      • classB.h
      • classB.test.h
    • クラスC
    • ...

この構造を使用すると、ライブラリをソースとして配布できます。ユーザーが行う必要があるのは-I/path/to/library、メイクファイルと#include "library/classA/classA.h"ソース ファイルに含めることだけです。

そして、結局のところ、インライン ヘッダーを使用すると、実際にはコード サイズが縮小されます。これを完全に分析したところ、ヘッダーのインライン コードにより、コンパイラは最終的なバイナリを約 5% 小さくできることがわかりました。

于 2013-12-02T16:10:16.360 に答える
0

ライブラリは、あなたが挙げた 3 つの選択肢の中で (私の意見では) 最良の選択肢です。次に、インクルード パスにヘッダー ファイルを指定し、リンカー パスにライブラリを指定します。

ライブラリをソース コード形式でも配布したいので、中央リポジトリで圧縮アーカイブ (gzip、7-zip、tarball、またはその他の推奨形式) を提供したいと考えています。

于 2013-07-30T19:55:36.447 に答える