【问题标题】:Boost::log::string_literal construction issueBoost::log::string_literal 构造问题
【发布时间】:2014-06-02 16:53:40
【问题描述】:

我尝试使用没有硬编码的宏BOOST_LOG_NAMED_SCOPE 失败(例如,没有BOOST_LOG_NAMED_SCOPE("bla"),但BOOST_LOG_NAMED_SCOPE(some_variable);这个宏在boost::log::string_literal 内部使用,而std::string 没有C'tor或char*。它唯一接受的是const char[](不是const char*)——这对我没有任何帮助,因为我无法对其进行硬编码——这个值必须从函数中检索。

所以,我需要找到一种方法来使用std::stringchar* 构造boost::log::string_literal,或者以某种方式编辑const char[]...(我还尝试创建一个char[] 并将其转换为@ 987654334@,但是失败了)

【问题讨论】:

    标签: boost boost-log boost-logging


    【解决方案1】:

    嗯。 “字符串文字”说明了一切。它只适用于文字,而那些 根据定义(在标准中)char const[]

    这种设计决策(使名称在编译时已知并固定)可能有几个原因。从概念上讲,它将使日志记录“可预测”(如果范围名称不同,您将如何解释日志?),并且可能与性能有关(它甚至可以用于基于范围名称静态禁用某些日志记录,但是根据编译器的不同,输出格式等其他方面的性能可能会有所提高)。

    因此,您可以不希望对事物进行硬编码,但不希望在执行此操作时使用需要字符串文字的宏。

    现在,您可以使用适当类型的extern 变量 (extern char const some_scope_name[]),我想这至少可以让您有机会在另一个翻译单元中定义值。 p>

    【讨论】:

    • Tnx。我需要这个的原因是仅使用文件名获取日志记录(而不是完整路径,因为范围属性给出了)。我想我会使用特殊的格式化函数(使用 boost::bind 将其附加到接收器)来执行此操作,或者我将为项目中的每个文件使用文件名宏(我将手动编写或通过脚本)并使用 BOOST_LOG_NAMED_SCOPE
    猜你喜欢
    • 2023-03-27
    • 2011-03-29
    • 1970-01-01
    • 1970-01-01
    • 2014-03-02
    • 2015-07-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多