私はこれまで1つのディレクトリに保持し、それらを必要とするプロジェクトディレクトリから参照してきた多くの共通モジュールを構築しました。
これを行うためのより良い方法があるかどうか疑問に思いましたか?
共通モジュールとそれらを使用するコードはどちらもC++で記述されています。
私はこれまで1つのディレクトリに保持し、それらを必要とするプロジェクトディレクトリから参照してきた多くの共通モジュールを構築しました。
これを行うためのより良い方法があるかどうか疑問に思いましたか?
共通モジュールとそれらを使用するコードはどちらもC++で記述されています。
静的ライブラリを作成してリンクすることをお勧めします。DLLよりもはるかに単純で、バージョン管理について心配する必要はありません。また、一般的なモジュールの場合と同じように、すべての面でDLLを操作できます。
編集:基本的に、静的ライブラリはオブジェクトファイルのコレクションです。Visual Studioを使用している場合は、静的ライブラリプロジェクトを作成(またはプロジェクトの出力タイプを変更)して、アプリケーションにリンクできる.libファイルを作成できます。GCCを使用している場合は、「ar」を使用して、一連の.oファイルからライブラリファイルを作成し、それをアプリケーションに再度リンクできます。
プライベートツールセットの管理と改善は、プログラマーにとって重要なことです。私は個人的に常に「できるだけ早く、簡単に」アプローチを選びます。
それらがリンクされて私の仕事に含まれるのが早ければ早いほど、私は「家にいる」と感じるのが早くなります。私は時々、すべてのオーダーラインを捨てて、それらをデフォルトのライブラリにチャックし、パスを含めます。(もちろん、それは本当にお勧めしませんが、それは迅速で簡単です)
通常のlibを使用すると、含まれる頭痛の種が少なくなるため、なぜdllを使用するのかわかりません。
ヒント:それらから別のプロジェクトを作成します。それらを中央の論理的な場所に配置します。(多分myWorkspace / MyLibs)作業中のプロジェクトごとにツールセットが成長/変更/改善される可能性があるため、作業環境をセットアップして、すばやく切り替え、何かを追加してから元のプロジェクトに戻ることができるようにすることがあります。この場合、IDEにプロジェクトの依存関係として含めると、自動的にビルドしてから再リンクできるので便利です。これは、ほとんどすべてのIDEで簡単です。
ただし、別の問題は雇用主です。彼らは通常、あなたが彼らのプロジェクトに持ち越すものについて警戒しています。特に、ソースをそれらに近づけたい場合。しかし、これは別の質問の話です;)
実行可能ファイルのサイズが小さくなるように、それらをdllに入れるのが好きです。