このライブラリーは、個別にコンパイルされる要素を持つ。これは、スタートガイドに記述されたとおりにビルドされるべきである。特筆すべきこととして、もしあなたのアプリケーションが1つ以上のBoost.Logを使用するモジュール（たとえば、exeや1つ以上のdll）から成るのであれば、このライブラリーは共有オブジェクトとしてビルドされなければならない。もし、Boost.Logを使用する、単一の実行ファイルや単一のモジュールであるならば、あなたは、このライブラリーを静的ライブラリーとしてビルドできる。
このライブラリーはいくつかの構成マクロをサポートする：
- BOOST_LOG_DYN_LINK
- ユーザーコードの中で定義された場合、このライブラリーは動的にロードされるライブラリー（dllやso）であると前提する。それ以外の場合、ライブラリーは静的に組み込まれるものと前提する。このマクロは、ログをとる利用者アプリケーションのすべてのコンパイル単位で定義されるか、あるいはされないか、どちらか一方でなければならない。このマクロは、自動リンキングをサポートする環境においては、これを補助する。
- BOOST_ALL_DYN_LINK
- BOOST_LOG_DYN_LINKと同じだが、すべてのBoostライブラリーに同様に影響する。
- BOOST_LOG_NO_THREADS
- 定義された場合、マルチスレッドサポートを無効にする。これは、ライブラリーと利用者コードのコンパイルの両方に影響する。スレッドのサポートが無いことが検出された場合、このマクロは自動的に定義される。
- BOOST_LOG_WITHOUT_CHAR
- 定義された場合、charによってログをとる事を無効にする。これは、ライブラリーと利用者コードのコンパイルの両方に影響する。
- BOOST_LOG_WITHOUT_WCHAR
- 定義された場合、wchar_tによってログをとる事を無効にする。これは、ライブラリーと利用者コードのコンパイルの両方に影響する。
- BOOST_LOG_NO_QUERY_PERFORMANCE_COUNTER
- このマクロはWindowsにおいてのみ機能する。これは、ライブラリーと利用者コードのコンパイルの両方に影響する。定義された場合、タイマー属性において、QueryPerformanceCounter関数のサポートを無効にする。これは時間の読み取りにおける重大な非正確性をもたらす。このマクロは、古いAMD Athlon CPUにおける潜在的な問題（これやこれ）を解決する事が意図されている。また、このAPIの正常な動作を失敗させる可能性のあるチップセットがあることも知られている（ここを参照せよ）。
- BOOST_LOG_USE_NATIVE_SYSLOG
- ライブラリーのコンパイルのみに影響する。もし何らかの理由でネイティブsyslogのサポートが自動的に検出されなかった場合、これを有効にするためにこのマクロを定義する。
- BOOST_LOG_WITHOUT_SETTINGS_PARSERS
- ライブラリーのコンパイルのみに影響する。定義された場合、設定のパースに関連するすべての機能がビルドされない。これはバイナリーのサイズを大きく減らす事ができる。
- BOOST_LOG_WITHOUT_DEBUG_OUTPUT
- ライブラリーのコンパイルのみに影響する。定義された場合、Windowsにおけるデバッガー出力のサポートがビルドされない。
- BOOST_LOG_WITHOUT_EVENT_LOG
- ライブラリーのコンパイルのみに影響する。定義された場合、Windowsにおけるイベントログのサポートがビルドされない。このマクロを定義する事は、メッセージコンパイラーを不要にする。
- BOOST_LOG_WITHOUT_SYSLOG
- ライブラリーのコンパイルのみに影響する。定義された場合、syslogバックエンドのサポートがビルドされない。
- BOOST_LOG_NO_SHORTHAND_NAMES
- 利用者コードのコンパイルのみに影響する。定義された場合、いくつかの非推奨の短縮マクロ名が無効になる。
- BOOST_LOG_USE_WINNT6_API
- ライブラリーと利用者コードのコンパイルの両方に影響する。このマクロはWindowsにおいてのみ機能する。定義された場合、このライブラリーは、より効率的なコードを生成するために、Windows NT 6（VistaとServer 2008）およびそれ以降のAPIを使用する。加えてこのマクロは、このライブラリーのいくつかの実験的な機能を有効にする。しかしながら、バイナリーはNT 6より古いWindowsでは動作しなくなる。この機能を使用するために、Platform SDK 6.0およびそれ以降が必要とされる。
- BOOST_LOG_USE_COMPILER_TLS
- ライブラリーのコンパイルのみに影響する。このマクロは、コンパイラー組み込みのTLS（スレッドローカル記憶域）サポートを有効にする。特定の用法の制限が許容できるならば、このマクロを定義する事でBoost.Logの性能を改善するかもしれない。以下のコメントを参照せよ。
bjam --with-log variant=release define=BOOST_LOG_WITHOUT_EVENT_LOG define=BOOST_LOG_USE_WINNT6_API stage
しかしながら、このライブラリーと利用者のプロジェクトの両方において自動的に定義するために、"boost/config/user.hpp"に構成マクロを定義するほうがより便利かもしれない。もし何もオプションが指定されない場合、このライブラリーはもっとも包括的な構成を試みる。この構成には、すべての文字型と対象の環境で有効な機能が含まれる。
このログライブラリーは、いくつかの、同様にビルドが必要なBoostライブラリーを使用する。これらは、Boost.Filesystem、Boost.System、Boost.DateTimeおよびBoost.Threadである。これらのビルド手順の詳細については、それぞれの文書を参照すること。
最後に言及すべき事として、このライブラリーは、ライブラリーと利用者コードのコンパイル時に実行時型情報（RTTI）が有効にされていることを要求する。これは通常、あなたのプロジェクトでRTTIのサポートが無効にされていないことを確認する以外には、何も必要としない。
コンパイラー組み込みのTLSについてのノート
広く使用されているコンパイラーの多くは、TLS（このライブラリーのいくつかの場所で使用されている）を管理するための組み込み機能をサポートしている。この機能は、C++11標準にも含まれている。一般的に、これらの組み込み機能は、Boost.ThreadやネイティブOS APIなど、あらゆる代替実装よりずっと効率的なTLSへのアクセスを許可する。しかしながらこの機能はいくつかの注意点を持つ：- アプリケーションの実行時に動的にロードされる共有オブジェクトにおいてTLSが定義された場合、いくつかのOSはそれらの組み込み機能の使用をサポートしない。これらのシステムには、LinuxやVistaより古いWindowsが含まれる。Windows Vistaおよびそれ以降では、この問題は存在しない。
- TLSは、グローバルコンストラクターとデストラクターから安全にアクセスできないかもしれない。少なくとも、WindowsのMSVC 8.0ではこの問題が知られている。
- 実行ファイルはBoost.Logライブラリーとリンクされなければならない。ライブラリーは実行時に動的にロードされるべきではない。
- アプリケーションは、ロギングをグローバルコンストラクターとデストラクターから使用してはならない。
No comments:
Post a Comment