C++では、デファクトスタンダードのロギングツールはありません。私の経験では、店は独自のものです。しかし、再利用可能なソフトウェアコンポーネントを作成しようとすると、少し問題が生じます。システム内のすべてがロギングコンポーネントに依存している場合、ソフトウェアの再利用が少なくなり、基本的に下流のプロジェクトでロギングフレームワークを実際に必要なコンポーネントとともに使用する必要があります。C++ログフレームワークは再利用性を犠牲にしますか？
IOC（依存性注入）は、コンポーネントがログの抽象化に依存する必要があるため、実際には問題に役立ちません。ロギングコンポーネント自体は、ファイルI/O、トリガーメカニズム、およびその他の望ましくない依存性に依存関係を追加できます。
独自のログフレームワークに依存関係を追加すると、コンポーネントの再利用性が犠牲になりますか？
はい。しかし、この場合は依存性注入が役立ちます。
抽象ログベースクラスを作成し、使用するログフレームワークの実装を作成できます。あなたのコンポーネントは抽象基本クラスに依存しているだけです。そして、必要に応じて依存関係を実装します。
はい、メンデルトは正しいです。私たちは私たちの製品でこれを正確に行います。すべてがILoggerの抽象インターフェースに依存しますが、それは他のものに依存しません。通常、実行可能なDLLまたは高レベルのDLLは、実際に実装されたLoggerインタフェースを構築して注入するものです。
再コンパイルされないライブラリをビルドしようとしているが、ロギングインターフェイスを提供したい場合は、（ライブラリの）ユーザーがコールバックを提供できるようにするのがよいでしょう。
ライブラリで初期化する際、コールバックを指定する必要があります。次に、グルーコードは、それらが持っているものと同じように再生できるようにするためのものです。
コールバックのシグネチャを標準機能のように見えるようにすることができれば、実際には使用できない可能性があります。
さらに、呼び出し元はライブラリからコンポーネントを複数回インスタンス化している可能性があり、リソースの競合またはスレッドの問題については、それぞれに異なるロガーコールバックを提供する必要があります。
+1私はこの厳密な状況にありますが、私のプロジェクトの主な実装では抽象的なログフレームワークがあり、必要な追加情報を記録しています...しかし、（別の）ログフレームワークを持つライブラリを使用していますが、彼らはまた、フレームワークをカプセル化するオブジェクトが渡されることを期待しています。オブジェクトを構築し、現在のログフレームワークの観点から実装します。 – Arafangion