0

ハードコーディングなしでマクロを使用しようとして失敗しましたBOOST_LOG_NAMED_SCOPE(たとえば、 no BOOST_LOG_NAMED_SCOPE("bla"), but BOOST_LOG_NAMED_SCOPE(some_variable); このマクロは、またはboost::log::string_literalの C'tor を持たないa 内で使用します。受け入れる唯一のものは(NOT ) です-これは役に立ちません)ハードコーディングできないため、この値は関数から取得する必要があります。std::stringchar*const char[]const char*

したがって、 or を使用して構築する方法を見つける必要がありますboost::log::string_literal。std::stringまたはchar*、何らかの方法で編集する方法を見つける必要がありconst char[]ます (また、 a を作成してchar[]にキャストしようとしましたconst char[]が、失敗しました)。

4

1 に答える 1

0

うーん。「文字列リテラル」がすべてを物語っています。リテラルでのみ機能し、それらは定義によるものです（標準では、つまり）char const[]。

この設計上の決定 (コンパイル時に名前を認識して修正するため) には、いくつかの理由が考えられます。概念的には、ロギングを「予測可能」にし (スコープ名が異なる場合、ログをどのように解釈しますか?)、パフォーマンスに関係する可能性があります (スコープ名に基づいて一部のロギングを静的に無効にするために使用することもできますが、出力フォーマットのような他のものは、コンパイラによってはパフォーマンスが向上する可能性があります)。

したがって、物事をハードコーディングしたくない場合もありますが、そうしている間に文字列リテラルを必要とするマクロを使用したくない場合があります。

これで、適切な型 ( ) の変数を使用できるようになりました。これにより、少なくとも別の翻訳単位で値を定義する機会が得られると思います。externextern char const some_scope_name[]

于 2014-06-02T20:27:20.277 に答える