boost-log-ライブラリ使用履歴
3460 ワード
最近ログライブラリ全体を作りたいと思っています.以前log 4 cplusを使っていましたが、boostが1.54バージョンを発売したのを見て、logライブラリがありました.このロゴは紹介を見てから使ってみました.主な応用シーンは,複数のモジュール(so,dll)に使用させることである.シーンは1つのプログラムで、複数のモジュールで、モジュールは単独のsoで、印刷したログで、同じファイルに出力します.
最初の頃、コンパイルされたboostライブラリは静的ライブラリで、コンパイルされたものは.aタイプのファイルが多い.1つのログモジュールで提示した後、別のモジュールで使用するとboost::log::core::get()で取得したポインタが異なることに気づきましたが、コードを見ていると、彼は単例だと説明していたのに、長い間困惑していました.結果は明らかで、boost::log::core::get()で取得したポインタが異なり、他の場所で初期化されたものは、効果がないに違いない.どこが原因なのか、コードで検索を続けます.core.cppではcoreクラスがimplementationクラスを使用し、implementationがlazyを継承しているのが見えます.singleton、このクラスでは、単一の例を取得するときに、非常に特殊なものを使用します:_COUNTER__(windows)と_LINE__(LINUX)、異なるモジュールでは、異なる値となり、異なる変数名が生成され、boost::log::core::get()の値が異なる.
boostのlogドキュメントを表示して、内容を検索します.
If asynchronous logging is used in a multi-module application, one should decide carefully when to unload dynamically loaded modules that write logs. The library has many places where it may end up using resources that reside in the dynamically loaded module. Examples of such resources are virtual tables, string literals and functions. If any of these resources are still used by the library when the module in which they reside gets unloaded, the application will most likely crash. Strictly speaking, this problem exists with any sink type (and is not limited to sinks in the first place), but asynchronous sinks introduce an additional problem. One cannot tell which resources are used by the asynchronous sink because it works in a dedicated thread and uses buffered log records. There is no general solution for this issue. Users are advised to either avoid dynamic module unloading during the application's work time, or to avoid asynchronous logging. As an additional way to cope with the problem, one may try to shutdown all asynchronous sinks before unloading any modules, and after unloading re-create them. However, avoiding dynamic unloading is the only way to solve the problem completely.
大まかに説明したように,マルチモジュールのアーキテクチャでは,使用する際に注意すべき点がある.
マルチモジュールの件が解決したと思って、プロファイルを使用して、logライブラリをロードする準備をして、新しい問題が発生しました.ネットを見て、みんなはすべて新しく1つのログの登録を定義して、それから、set_を使いますformatは出力モードを設定します.ただし、コンフィギュレーションファイルを使用してロードする使用(boost::log::init_from_stream)ではsinkメソッドを取得できず(個人的には見つかりませんでしたが、あれば教えてください、ありがとうございます)、ログにログレベルを追加することはできません.その後、logライブラリ自体のboost::log::trivial::severity_level、やはりログの等級がなくて、これは不思議です!
調べてみると、stackoverflowで原因を見つけ(経験:問題があれば、出会ったのは自分ではないかもしれませんが、googleはまだ希望があります)、彼らはこれがバグだと言っています(この話を聞いて、あなたは少し気持ちがいいかもしれません).
Webサイトは次のとおりです.http://stackoverflow.com/questions/18014335/boost-log-severity-logger-init-from-stream
解決策はformatとfilterを再定義することであり、具体的な関数は以下の通りである.
自分の新しいログ登録を使用する場合は、traivaila.hppとtraivail.cppの実装を直接参照することが望ましい.具体的にどのように実現するかは、boost-log.pdfのヘルプドキュメントに詳しく説明されています.タイトル:
Extending the library
Extending library settings support
Adding support for user-defined types to the formatter parser
Adding support for user-defined types to the filter parser
作者:wcl_hjs!
みんなで交流しましょう!
最初の頃、コンパイルされたboostライブラリは静的ライブラリで、コンパイルされたものは.aタイプのファイルが多い.1つのログモジュールで提示した後、別のモジュールで使用するとboost::log::core::get()で取得したポインタが異なることに気づきましたが、コードを見ていると、彼は単例だと説明していたのに、長い間困惑していました.結果は明らかで、boost::log::core::get()で取得したポインタが異なり、他の場所で初期化されたものは、効果がないに違いない.どこが原因なのか、コードで検索を続けます.core.cppではcoreクラスがimplementationクラスを使用し、implementationがlazyを継承しているのが見えます.singleton、このクラスでは、単一の例を取得するときに、非常に特殊なものを使用します:_COUNTER__(windows)と_LINE__(LINUX)、異なるモジュールでは、異なる値となり、異なる変数名が生成され、boost::log::core::get()の値が異なる.
boostのlogドキュメントを表示して、内容を検索します.
If asynchronous logging is used in a multi-module application, one should decide carefully when to unload dynamically loaded modules that write logs. The library has many places where it may end up using resources that reside in the dynamically loaded module. Examples of such resources are virtual tables, string literals and functions. If any of these resources are still used by the library when the module in which they reside gets unloaded, the application will most likely crash. Strictly speaking, this problem exists with any sink type (and is not limited to sinks in the first place), but asynchronous sinks introduce an additional problem. One cannot tell which resources are used by the asynchronous sink because it works in a dedicated thread and uses buffered log records. There is no general solution for this issue. Users are advised to either avoid dynamic module unloading during the application's work time, or to avoid asynchronous logging. As an additional way to cope with the problem, one may try to shutdown all asynchronous sinks before unloading any modules, and after unloading re-create them. However, avoiding dynamic unloading is the only way to solve the problem completely.
大まかに説明したように,マルチモジュールのアーキテクチャでは,使用する際に注意すべき点がある.
マルチモジュールの件が解決したと思って、プロファイルを使用して、logライブラリをロードする準備をして、新しい問題が発生しました.ネットを見て、みんなはすべて新しく1つのログの登録を定義して、それから、set_を使いますformatは出力モードを設定します.ただし、コンフィギュレーションファイルを使用してロードする使用(boost::log::init_from_stream)ではsinkメソッドを取得できず(個人的には見つかりませんでしたが、あれば教えてください、ありがとうございます)、ログにログレベルを追加することはできません.その後、logライブラリ自体のboost::log::trivial::severity_level、やはりログの等級がなくて、これは不思議です!
調べてみると、stackoverflowで原因を見つけ(経験:問題があれば、出会ったのは自分ではないかもしれませんが、googleはまだ希望があります)、彼らはこれがバグだと言っています(この話を聞いて、あなたは少し気持ちがいいかもしれません).
Webサイトは次のとおりです.http://stackoverflow.com/questions/18014335/boost-log-severity-logger-init-from-stream
解決策はformatとfilterを再定義することであり、具体的な関数は以下の通りである.
boost::log::register_simple_formatter_factory<boost::log::trivial::severity_level, char>("Severity");
boost::log::register_simple_filter_factory<boost::log::trivial::severity_level, char>("Severity");register_simple_formatter_factory Severity (out) ( ， )
register_simple_filter_factory Serverity (filter)( ， ， )自分の新しいログ登録を使用する場合は、traivaila.hppとtraivail.cppの実装を直接参照することが望ましい.具体的にどのように実現するかは、boost-log.pdfのヘルプドキュメントに詳しく説明されています.タイトル:
Extending the library
Extending library settings support
Adding support for user-defined types to the formatter parser
Adding support for user-defined types to the filter parser
作者:wcl_hjs!
みんなで交流しましょう!