C ++には、デファクトスタンダードのロギングツールはありません。私の経験では、ショップは独自にロールバックします。ただし、再利用可能なソフトウェアコンポーネントを作成しようとすると、少し問題が発生します。システム内のすべてがロギングコンポーネントに依存している場合、これによりソフトウェアの再利用性が低下し、基本的に、ダウンストリームプロジェクトは、本当に必要なコンポーネントとともにロギングフレームワークを使用する必要があります。
コンポーネントはロギングの抽象化に依存する必要があるため、IOC（依存性注入）は実際には問題を解決しません。ロギングコンポーネント自体が、ファイルI / O、トリガーメカニズム、およびその他の不要な依存関係に依存関係を追加する可能性があります。
独自のロギングフレームワークに依存関係を追加すると、コンポーネントの再利用性が犠牲になりますか？
はい。ただし、この場合、依存性注入が役立ちます。
抽象ロギングの基本クラスを作成し、使用するロギングフレームワークの実装を作成できます。コンポーネントは、抽象基本クラスに依存しているだけです。そして、必要に応じて、すべての依存関係とともに実装を注入します。
はい、メンデルトは正しいです。私たちはまさにこれを製品で行っています。すべては ILogger 抽象インターフェイスに依存しますが、それ以外には依存しません。通常、実行可能ファイルまたは高レベルの DLL は、実際に実装された Logger インターフェイスを構築し、それを注入するものです。
再コンパイルされないライブラリを構築しようとしているが、ロギング インターフェイスを提供したい場合は、(ライブラリの) ユーザーがコールバックを提供できるようにすることがおそらく良い方法です。
ライブラリでロギングを初期化する際に、コールバックを指定する必要があります。その後、グルーコードは、彼らが持っているものでうまく機能するようにするためのものです。
コールバックのシグネチャを、常に使用できる標準関数のように見せることができれば、実際にロガーがない場合に簡単なデフォルト オプションを提供できます。
さらに、呼び出し元がライブラリからコンポーネントを複数回インスタンス化している可能性があり、リソースの競合やスレッド化の問題のために、それぞれに異なるロガー コールバックを提供する必要があります。