ロギングライブラリの比較

• C ++ロガーを提案しますか？ （C ++ロギングフレームワークの提案）
• 最も効率的なスレッドセーフC ++ロガーとは何ですか？ （最も効率的なスレッドセーフC ++ロガーとは）
• Cゲームのロギングライブラリ
• 非同期スレッドセーフC ++ロガー？ （C ++の非同期スレッドセーフロギング）

やる気

1. 最初のグループについては、この記事では「ロガーXが最適です」という推奨事項よりもロガーの広範な比較を示します。
2. 2番目のグループの場合、この記事では現在の技術レベルについて説明し、おそらく「既製の方が使いやすい」または「すごい作業がたくさんありますが、もっとうまくいくことができます」という方向にスケールを変えるでしょう。
3. 3番目の最も退屈なグループについては、この記事が3週間の研究の少なくとも1つを節約することを願っています。業界全体で、これは驚くべき工数になります。

ロガーとその主なパラメーター

1. パンテイオス
2. グログ
3. log4cpp
4. P7
5. G3log
6. Spdlog
7. イージーロギング
8. Boost.Log（巨大なBoostライブラリの一部）

1. 独自のライセンスwww.boost.org/LICENSE_1_0.txt
2. www.boost.org/doc/libs/1_62_0/libs/log/doc/html/log/installation.html
3. Boostをコンパイルできるプラットフォームおよびコンパイラは他にも多数ありますが、それらは公式にはサポートされておらず、おそらく追加の作業が必要になります。

ドキュメントと依存関係

1. 弱い依存関係-コードの一部はサードパーティのソリューションに依存しますが、コンパイルを妨げませんが、機能を部分的に制限します。
   
   
2. ヘッダーファイルのみ-ライブラリは、プログラムの各ソースファイルに含める必要がある1つまたは複数のヘッダーファイルの形式で配布されます; Easyloggingの場合、コンパイル速度は大幅に低下します。 しかし、この状況から抜け出す方法があります-これらのプロジェクトをライブラリの形でコンパイルし、既に接続することですが、これにはプロジェクトの作成にさらに時間がかかります。

ロガータイプ、メモリ消費制御、スレッドセーフ

• 同期-ログ（..）関数の呼び出しとファイルへの書き込みは、1つのストリームから同期的に発生します
• 非同期-Log（..）関数の呼び出しは、他のスレッドが書き込み中にメッセージキューのみを更新するため、ユーザーストリームからLog（..）関数を呼び出すのにかかる時間を短縮し、その結果、ユーザーストリームの最大パフォーマンスが達成され、Log呼び出しの遅延が最小化されます（..）関数。

1. タイプ番号1：Log（..）関数の呼び出しはアトミックである必要があると考える人もいるため、ファイル内のログメッセージの順序は00:00-> 00:01-> 00:02のように連続します。
   
   
2. タイプNo. 2：他の人は、最大のパフォーマンスを達成するために、Log（..）関数呼び出しの原子性を犠牲にして、ファイル内のログメッセージがインターリーブされるという事実に耐えることができると考えています。たとえば、00：00-> 00:05-> 00 ：01。

1. 非同期モードは実験状態です
2. シャッフルされないタイムスタンプとメッセージ
3. タイムスタンプとメッセージがシャッフルされる場合があります
4. デフォルトでは使用できません。マクロELPP_THREAD_SAFEを有効にする必要があります
5. 制御されていないメモリ割り当て、高負荷下では数百メガバイトを割り当てることができる、著者のコメント： kjellkod.wordpress.com/2014/08/16/presenting-g3log-the-next-version-of-the-next-generation-of-the-next-generation-of-loggers
   

   g2logまたはg3logの場合、std ::キューが使用されます。内部的にはstd :: dequeです。 制限はありませんが、std :: vectorよりもはるかにメモリ耐性があります。 内部的に、キューはshared_queue.hpp内でラップされます。
   

   
   
6. キューの長さは要素で設定できます。初期形式の要素のサイズは88バイト+テキストメッセージ（30〜160バイト）です。 最適なパフォーマンスを得るには、キューサイズを100万メッセージに設定することをお勧めします。これは、ロギングライブラリのみで120メガバイトから250メガバイトのメモリコストに変換されます。
7. メッセージのシーケンスはデフォルトのライブラリでは保証されていません。異なるストリームからログを記録する場合、結果のファイルにタイムスタンプを混在させることができます： 「マルチスレッドアプリケーションでログレコードの順序が弱いのはなぜですか？」ライブラリの作成者は、「unbounded_ordering_queue」 。 ソートが実行される属性「RecordID」
8. デフォルトでは、ライブラリは「unbounded_fifo_queue」を使用します。これにより、集中的なロギングでメモリ消費が制御不能に増加します。 追加の構成には「bounded_fifo_queue」を使用できます。 この場合、要素でキューの長さを指定できます。 各項目（図書館用語の記録）は約1KBかかります

プロセス障害処理

• 自動、ライブラリ自体はすべてのベクトルを設定し、すべてを単独で行います。このソリューションの大きな欠点は、インターセプトされた信号の不足と、クラッシュダンプファイルまたはフラッシュバッファーを保存するためにクラッシュ自体を処理したいアプリケーションの干渉です。
• 手動-ライブラリは、フォールをインターセプトしてバッファをフラッシュするためのプリミティブを提供し、アプリケーション自体がインターセプターをインストールするタイミングと方法、およびフォールの場合の処理​​を決定します。
• 落ちて、日常生活の問題

1. 以下のシグナルがインターセプトされます：SIGSEGV、SIGILL、SIGFPE、SIGABRT、SIGBUS、SIGTERM。
2. SIGSEGV、SIGILL、SIGFPE、SIGINT、SIGABRT、SIGBUS、SIGTERM、SIGBUS、PureVirtualCall、VectoredException、Newhandler、InvalidParameterHandler、status_access_、exception_array_bounds_exceeded、exception_datatype_misalignment、exception_flt_divide_by_zero、exception_flt_stack_check、EXCEPTION_ILLEGAL_INSTRUCTION、EXCEPTION_INT_DIVIDE_BY_ZERO、exception_noncontinuable_exception、exception_priv_instruction、EXCEPTION_STACK_OVERFLOW次の信号を傍受
3. 次のシグナルがインターセプトされます：SIGSEGV、SIGILL、SIGFPE、SIGABRT、SIGBUS、SIGTERM、ゼロによるDiv、不正なprintf、範囲外、アクセス違反、std :: future_error
4. github.com/gabime/spdlog/issues/55-欠陥は2015年に「クローズ」されました。 この方向での作業は予測されていません。
5. 以下のシグナルがインターセプトされます：SIGABRT、SIGFPE、SIGILL、SIGSEGV、SIGINT
6. 同期モードの場合でも、プロセスに障害が発生するとデータ損失のリスクがあります;非同期モードを使用する場合、データ損失のリスクは非常に高くなります

ロギングスタイルと出力（シンク）

• 可変引数のリストを持つ関数（prinfスタイル）
• 演算子のオーバーロード「<<」

1. 使用された場合、Printfは例外をスローしましたが、これはおそらく一時的な問題です。
2. そのサーバーは、最大のパフォーマンスを実現するために使用されます。 このサーバーは無料ですが、残念ながらWindowsのみをサポートしており、明らかにQtに基づいており、作成者にLinuxサポートのリクエストが送信されました。 テスト構成でネットワークを介してログを送信する速度は、CPUのロード時に毎秒約350万でした-13％。 パフォーマンステストについては、次の章で詳しく説明します。
3. 公式ディストリビューションには、ファイルローテーションとコンソールをサポートするSinkは含まれていませんが、これらの拡張機能はgithub.com/KjellKod/g3sinksからダウンロードできます
4. Printfライブラリ関数の文字列形式は標準形式と互換性がないため、あるロガーを別のロガーに簡単に置き換えることは困難です
5. nullptr文字列をロガーへの引数として渡すと、セグメンテーション違反/アクセス違反が発生します
6. 最も生産的なシンク：バイナリファイル、Baical

ロガーの初期化

1. ロガーパラメーターの詳細かつ適切に設定された設定は、おそらく最も詳細です。
2. 他のすべてのロガーでは、コマンドラインパラメーターを処理するために、int main（int argc、char * argv []）関数から手でロガーに渡す必要があります。 このロガーでは、これらのパラメーターはプログラム/モジュール（dllなど）の任意の部分から自動的にインターセプトできます。
3. ライブラリは、構成ファイルを介した構成のための最も基本的なプリミティブのみを提供します 。 この問題のより完全な議論はここで見つけることができます。 そして結論として

   有効なエントリは、シンク、フィルタなどを実装するソースコードから派生しているため、構成ファイル形式のエントリの説明を見つけるのは難しいように思えます。 この実装はユーザー定義であってもよいため、明示的な構成フォーマットの説明を提供することは不可能です

フィルタリング設定

1. フィルタリングを整理するには、フロントエンドを開発する必要があります
2. データがネットワーク経由で送信される場合にのみサポートされます;ローカルファイルに書き込む場合、サーバーは詳細レベルにアクセスできません。
3. グローバルレベルに加えて、各モジュールのレベルを設定できます。
4. 各ロガーの階層的なロギングとレベルの個別設定
5. デフォルトでは無効になっており、マクロG3_DYNAMIC_LOGGINGによって有効になっています。その後、すべてのロガーのレベルを手動で設定できます。 パフォーマンスが大幅に低下します。
6. 製造元によってサポートが発表されましたが、機能させることはできませんでした。使用中に機能が開発中または放棄されたようです。

Unicodeサポート

1. 結果のログファイルにUnicodeトークンがなく、ビューアでのエンコーディングを自分で選択する必要があることを除いて、ほぼ完璧です。
2. サポートは要求されていますが、実装されていません。Unicode文字はログファイルに含まれていません。
3. START_EASYLOGGINGPPマクロはUnicodeをサポートしていません
4. UTF-16など、ANSI文字列を1つのメッセージに結合することはできません
5. Unicodeサポートは、Boost.Localeライブラリを使用して実行され、UTF-8 / 16/32およびその他の国のロケールのさまざまな形式に対する印象的な幅広いサポートが提供されますが、残念ながら、UTF-8ファイル形式でのみ初期化関数を使用してBoost.Logを動作させることができました同期ロガー「logging :: add_file_log」、他のすべての試行は失敗し、Unicode文字はファイルに到達しませんでした。おそらく、この機能を動作させるのに十分な時間です

ロガーへのアクセス

ファイルの回転

1. 名前の各ファイルには日付と時刻が含まれています。
2. オプション「最大。 ファイル数」は、最後のファイルのうちN個だけを保存することを許可します

時間精度

1. 1ミリ秒の粒度を取得できる場合もありますが、多くの場合、クォンタムは10ミリ秒です。

性能

• デフォルト設定
• メモリの均等使用の条件で
• シングルストリームモード
• マルチスレッドモードで

• ウィンドウ7x64（6.1.7601 Service Pack 1ビルド7601）
• Visual Studio 2015、アップデート2
• RAM：16Gb（DDR3-1600 / PC3-12800）
• CPU：Intel Core i7-870
• HDD：Samsung EVO SSD 850 256GB（SATA3）

• メッセージ番号
• ソースファイル名
• コード行番号
• ソース関数名
• ロガー/モジュール名
• レベル（エラー、警告、...）
• 時間
• 現在のスレッドのID（スレッドID）
• CPUコア番号
• テキストメッセージ

#include <stdio.h> #include <atomic> #include <thread> #include <vector> //Include specific logger headers #include "Logger headers ..." using namespace std; using namespace std::chrono; //Use this macro to switch on multi-threading mode //#define MULTI_THREAD int main(int argc, char* argv[]) { //Logger initialization //.. unsigned int thread_count = 4; unsigned int howmany = 1'000'000; vector<thread> threads; auto start = system_clock::now(); #if !defined(MULTI_THREAD) for(unsigned int i=0; i < howmany; i++) { //Has to be customized for every logger LOG(INFO) << " Message + all required information, #" << i; } #else howmany /= thread_count; for (int t = 0; t < thread_count; ++t) { threads.push_back(std::thread([&] { for(unsigned int i=0; i < howmany; i++) { //Has to be customized for every logger LOG(INFO) << " Message + all required information, #" << i; } })); } for(auto &t:threads) { t.join(); }; howmany *= thread_count; #endif auto delta = system_clock::now() - start; auto delta_d = duration_cast<duration<double>> (delta).count(); LOG(INFO) << "Time = " << (double)howmany / delta_d << " per second, total time = " << delta_d; //Logger uninitialization if necessary return 0; } 

シングルスレッド

1. 非同期ロギング
2. オプション "/P7.Pool=1024"でコンパイル-使用可能なメモリの合計量は1メガバイトです。
3. ほとんどの場合、ロガーはバッファーにデータを追加し、アプリケーションを終了すると記録が行われるため、測定は合成と見なすことができます。この作業には、ログ時間を1桁、ログを1秒、データを10秒保存する時間を超える時間がかかります。
4. ロガーが約250メガバイトのメモリを消費している間に、製造元が推奨する条件 "spdlog :: set_async_mode（1048576）"でログを記録する
5. 「spdlog :: set_async_mode（4096）」というメモリ消費量が等しい条件下でのロギング-この場合、ロガーには4k要素のバッファがあり、各要素は約250バイトを占有し、最終的には約1メガバイトのメモリ消費になります。
6. 録音は、UTF-16形式のテキストのバイナリファイルで実行されました。
7. メモリ消費が等しい条件（asynchronous_sink + text_file_backend + bounded_ordering_queue + block_on_overflow）でログインすると、キューの長さは1024要素であり、各要素は約1100バイトかかり、最終的には1 MBを少し超えるメモリ消費を与えます。
8. 総合テスト。 最も快適な状態、デフォルトのロガー構成（asynchronous_sink + text_file_backend + unbounded_fifo_queue）でのロギング。 メモリ消費に制限はありません。到着順にメッセージをソートすることはありません。 メモリ消費は1.8GBに固定されました。

4スレッド

1. 非同期ロギング
2. オプション "/P7.Pool=1024"でコンパイル-使用可能なメモリの合計量は1メガバイトです。
3. ほとんどの場合、ロガーはバッファーにデータを追加し、アプリケーションを終了すると記録が行われるため、測定は合成と見なすことができます。この作業には、ログ時間を1桁、ログを1秒、データを10秒保存する時間を超える時間がかかります。
4. ロガーが約250メガバイトのメモリを消費している間に、製造元が推奨する条件 "spdlog :: set_async_mode（1048576）"でログを記録する
5. 「spdlog :: set_async_mode（4096）」というメモリ消費量が等しい条件下でのロギング-この場合、ロガーには4k要素のバッファがあり、各要素は約250バイトを占有し、最終的には約1メガバイトのメモリ消費になります。
6. 録音は、UTF-16形式のテキストのバイナリファイルで実行されました。
7. メモリ消費が等しい条件（asynchronous_sink + text_file_backend + bounded_ordering_queue + block_on_overflow）でログインすると、キューの長さは1024要素であり、各要素は約1100バイトかかり、最終的には1 MBを少し超えるメモリ消費を与えます。
8. 総合テスト。 最も快適な状態、デフォルトのロガー構成（asynchronous_sink + text_file_backend + unbounded_fifo_queue）でのロギング。 メモリ消費に制限はありません。到着順にメッセージをソートすることはありません。 メモリ消費は1.8GBに固定されました。

フィルタリング

1. フィルタリングはデフォルトでは使用できません
2. フィルタリングを機能させることができませんでした

パフォーマンスの概要

（（10000 ms /テスト時間（ms））* 1 000 000メッセージ）/テストでのCPU使用率

結論

パンテイオス

• タイプセーフなテンプレートベースの呼び出し
• 優れた完全なドキュメント
• Unicodeをサポートする数少ないロガーの1つですが、いくつかの制限があります。
• 低メモリ消費
• サポートされている多数のシンク
• サポートされている多数のコンパイラ

• 開発は中止されたようです
• ロガーとシンク（ファイル、ネットワークなど）のコンパイラー段階での静的バインディング
• 強力なコンピューター上での間接的な結果でさえ、信じられないほど長いコンパイル-バイナリファイルのサイズ
• レビューされたすべてのロガーの中で最も低いパフォーマンス指標の1つ
• コード内のロガー構成のみ（構成ファイル、コマンドラインのサポートなし...）
• ファイルローテーションのサポートなし
• 同期実行、つまり すべてのSink遅延（たとえば、ファイルへの書き込み）は、コードの速度に影響します。
• 同じメッセージ内でUnicode文字列とANSI文字列を組み合わせる方法はありません
• 高い入場しきい値（非常に習得が難しく、紛らわしい）

1. 信じられないほど効率的で、他のすべての深刻なC ++診断ログライブラリよりも大幅に（最大2桁） 高速ですwww.pantheios.org/essentials.html

グログ

• ライブラリの理解と保守が簡単
• プロセス障害のサポート
• コマンドライン経由で設定する機能
• 低メモリ消費

• 非常に弱いドキュメント
• プロセスクラッシュの弱いサポート-限られた数のシグナル、Linuxのみ
• 高いメッセージフィルタリングのオーバーヘッド
• デバッグおよびリリースコードのパフォーマンスの複数のギャップ（最大9回）
• 同期実行、つまり すべてのSink遅延（たとえば、ファイルへの書き込み）は、コードの速度に影響します。
• アクティブな開発が一時停止しました
• Unicodeサポートなし
• タイムスタンプの精度が不十分です
• マルチスレッドテストでCPU消費量が最も高く、1つのスレッドと比較してロガーのパフォーマンスが非常に低い

log4cpp

• 生成されたドキュメント
• サポートされている多数のシンク
• 低メモリ消費
• 構成ファイルのサポート
• 優れたメッセージフィルタリングパフォーマンス

• 同期実行、つまり すべてのSink遅延（たとえば、ファイルへの書き込み）は、コードの速度に影響します。
• Unicodeサポートなし
• デバッグおよびリリースコードのパフォーマンスの複数のギャップ（最大10倍）
• 低い生産性（最後から2番目の場所）
• 行サイズは1024文字を超えてはいけません-そうでなければアサートします
• ログファイルへのパスが存在しない場合、例外がスローされます。

P7

ソフトウェア。

• 完全なドキュメント
• 高性能+タイムスタンプの高精度、最も近い競合他社SpdLogとの大きなギャップ
• Unicodeサポート
• メモリ消費を完全に制御
• 非同期-Log関数の呼び出しはデータの記録とは無関係であるため、関数の呼び出しの遅延は平準化されます。
• （「グローバル」変数の代わりに）共有メモリを使用してロガーとシンクにアクセスします。これにより、C＃やCなど、ライブラリがサポートする他の言語で記述された動的モジュールからでも、プロセスコードの任意の部分からロガーにアクセスできます
• キットには、C、C＃、Pythonのラッパーが含まれています
• ログに加えて、ライブラリはリアルタイムの記録と監視をサポートしています。
  
  テレメトリー

  
• 各デバイス、プロセス、またはモジュールのログレベルを（ネットワークを介して）リモートで制御し、テレメトリカウンターを有効/無効にする機能
• 考慮されるすべてのロガーの中で、パフォーマンスの面で最小のプロセッサ要件があります
• 複数の言語で利用でき、アプリケーションの異なる部分がC＃、C ++、Cで記述されている場合、すべて同じロガーを使用できます。
• 独自のテキストシンクを簡単に接続
• シンクの幅広い選択
• Baicalサーバーのカーネルはオープンソースプロジェクトであり、Windows、Linux 32/64でコンパイルできます。

• 複数のスレッドからロガーを集中的に使用すると、ロガーのパフォーマンスが低下します（2.3倍）（ログメッセージとタイムスタンプのシーケンスに対する支払い）
• バイナリデータ用の独自のシンクの設計は複雑です
• ログメッセージのシリアル化により、すべてのプロセッサコアを均等にロードすることはできません

G3log

• 良好なろ過率
• 残念ながらLinuxでのみ、プロセスクラッシュ（情報が利用可能な場合のスタックトレース生成）の処理
• 全体的に満足できるドキュメント
• 非同期-Log関数の呼び出しはデータの記録とは無関係であるため、関数の呼び出しの遅延は平準化されます。

• Unicodeサポートなし
• CPU消費量が多い一方で、パフォーマンスが弱い
• ほとんどの場合、ロガーはバッファにデータを追加し、アプリケーションを終了すると記録が行われ、この作業はロギング時間よりも桁違いに長いため、パフォーマンス測定は合成と見なすことができます。
• 完全な非同期-タイムスタンプとメッセージをグループにまとめて、または一度に1つずつ集中的にログを記録できます
• 無制御のメモリ割り当ては数百メガバイトに達し、場合によっては大量のログが記録されるギガバイトに達します。
• コードのみによるロガー構成
• タイムスタンプの精度が不十分です
• デバッグおよびリリースコードのパフォーマンスの複数のギャップ（最大30回）
• 高いCPU消費
• C ++ 11以降をサポートするコンパイラ

1. kjellkod.wordpress.com/2014/08/16/presenting-g3log-the-next-version-of-the-next-generation-of-loggers
2. kjellkod.wordpress.com/2015/06/30/the-worlds-fastest-logger-vs-g3log

Spdlog

• 全体的に満足できるドキュメント
• CPUは要求していません
• 非同期-Log関数の呼び出しはデータの記録とは無関係であるため、関数の呼び出しの遅延は平準化されます。
• メモリ消費の部分的な制御
• ヘルパーマクロの素敵なセット
• スピード、総合順位で2位、しかし1位の遅れは巨大です

• プロセス障害処理なし
• Printfライブラリ関数の文字列形式は、標準形式と互換性がないため、1つのロガーを別のロガーに簡単に置き換えることは難しく、実際には片方向チケットです
• 完全な非同期-タイムスタンプとメッセージをグループにまとめて、または一度に1つずつ混合して、結果のファイルに集中的にログを記録できます
• 最適なパフォーマンスを実現するには、約250〜300メガバイトのRAMを消費しますが、メモリ容量が減少すると、パフォーマンスは約18倍低下します。
• Unicodeサポートなし
• プロジェクトの各ファイルにこれらのファイルを含めるとコンパイルが大幅に遅くなるため、ヘッダーファイルのみをマイナスと見なします。プリコンパイル済みヘッダーを使用できます。
• コード内のロガー構成のみ
• 特に達成されたパフォーマンス（1ミリ秒のタイムスタンプ解像度で毎秒数十万から数十万のメッセージ）を考慮すると、タイムスタンプの精度は不十分です。
• C ++ 11以降をサポートするコンパイラ
• デバッグおよびリリースコードのパフォーマンスの複数のギャップ（最大74回）

イージーロギング

• 全体的に満足できるドキュメント
• CPUは要求していません
• 中程度のメモリ消費
• ヘルパーマクロの素敵なセット
• 設定ファイル、コマンドラインのサポート
• 多数のサポート対象プラットフォームを宣言しました

• 同期実行、つまり すべてのSink遅延（たとえば、ファイルへの書き込み）は、コードの速度に影響します。
• 低性能
• フィルタリングを取得できませんでした。おそらくオプションが開発中です
• Unicodeサポートは要求されますが、実際にはUnicode文字はファイルに到達せず、途中で失われます
• プロジェクトの各ファイルにヘッダーファイルを含めるとコンパイルが大幅に遅くなるため、マイナスと見なされるヘッダーファイルのみがプリコンパイル済みヘッダーを使用できます。
• タイムスタンプの精度が不十分です
• C ++ 11以降をサポートするコンパイラ
• デバッグおよびリリースコードのパフォーマンスの複数のギャップ（最大40回）
• デフォルトで無効になっている特別なマクロ（ELPP_THREAD_SAFE）でスレッドセーフを有効にする必要があります

Boost.log

• 同期および非同期ロギングのサポート（Log関数の呼び出しはデータ記録とは無関係であるため、関数の呼び出しの遅延は平準化されます）
• 基本的なニーズをカバーする十分なドキュメント
• ログエントリの属性（ストリーム番号、ソースファイル、カウンターなど）
• シンクごとのフォーマットがサポートされています
• フィルタリングに述語を使用する機能
• サポートされている多数のシンクを宣言しました
• Unicodeサポート
• 構成ファイルのサポート

• この記事で紹介した最も複雑でわかりにくいロギングライブラリの1つ。 完全に複雑なマクロとテンプレートの混合で構築されています。 ほとんどの時間は研究に費やされました。 「フードの下で」勉強するのにさらに多くの時間が費やされました。それがおそらく、たった一人が主な参加者の一人である理由です。
• 考慮されるすべてのロガーの中で最も低いパフォーマンス
• コードのセクションを実行するときのセグメンテーション違反/アクセス違反

   char *pStr = nullptr; //…. BOOST_LOG_SEV(lg, trace) << pStr; 

• タイムスタンプの精度は不十分ですが、そのようなパフォーマンスではそれほど重要ではありません（1期間に最大12個のメッセージ）
• デバッグおよびリリースコードのパフォーマンスに複数のギャップ（最大54倍）があるため、デバッグモードでは実行時間が完全に受け入れられなくなることに注意する必要があります（ログ記録に数十分）
• Unicodeサポートは十分にテストされた機能の印象を与えません（非同期ログの固定サイズのソートとFIFOを使用してファイルを入力することはできませんでした）
• 同期ロガーでもバッファデータの保存が重要であるという事実を考慮すると、プロセスエラーの処理はありません。重要なデータを失う重大なリスクがあります。
• ログエントリの属性は簡単ではありません。たとえば、元の関数の名前、ファイル、行番号などです。 属性の作成も簡単な作業ではありません。
• そのユーティリティを使用した複雑なコンパイルが、コンパイルされたバイナリも提供されていることに注意する必要があります、問題はすべてのBoostに共通です
• プロジェクトにライブラリを含めると、コンパイルとリンクが大幅に遅くなります（プリコンパイル済みヘッダーを使用している場合でも）
• ライブラリコードのすべてのセクションは例外生成でカバーされますが、独自のインターセプターをインストールすることができます。これにより、各呼び出しでロガーからの例外をキャッチしたくないユーザーの不便を軽減します。

まとめ