如何在C ++中嵌套的词法作用域可访问的作用域中声明静态信息?

时间:2018-03-21 17:38:22

标签: c++ c++11 logging spdlog

我想声明范围的标识符,这些标识符将用于自动填充最里面范围内的任何日志记录语句的字段。它们通常但不总是(例如lambdas,用{}引入的块)匹配封闭块的“名称”。

用法看起来像这样:

namespace app {

LOG_CONTEXT( "app" );

class Connector {
    LOG_CONTEXT( "Connector" );
    void send( const std::string &  msg )
    {
        LOG_CONTEXT( "send()" );
        LOG_TRACE( msg );
    }
};

} // namespace app

//                     not inherited
LOG_CONTEXT( "global", false );

void fn()
{
    LOG_DEBUG( "in fn" );
}

int main()
{
    LOG_CONTEXT( "main()" );
    LOG_INFO( "starting app" );
    fn();
    Connector c;
    c.send( "hello world" );
}

结果如下:

[2018-03-21 10:17:16.146] [info] [main()] starting app
[2018-03-21 10:17:16.146] [debug] [global] in fn
[2018-03-21 10:17:16.146] [trace] [app.Connector.send()] hello world

我们可以通过定义LOG_CONTEXT宏来获得最内部的范围,以便它声明一个结构。然后在LOG_*宏中,我们在其上调用静态方法来检索名称。我们将整个事物传递给一个可调用的对象,例如:

namespace logging {

spdlog::logger & instance()
{
    auto sink =
        std::make_shared<spdlog::sinks::ansicolor_stdout_sink_mt>();
    decltype(sink) sinks[] = {sink};
    static spdlog::logger logger(
        "console", std::begin( sinks ), std::end( sinks ) );
    return logger;
}

// TODO: stack-able context
class log_context
{
public:
    log_context( const char *  name )
        : name_( name )
    {}

    const char * name() const
    { return name_; }

private:
    const char *  name_;
};

class log_statement
{
public:
    log_statement( spdlog::logger &           logger,
                   spdlog::level::level_enum  level,
                   const log_context &        context )
        : logger_ ( logger  )
        , level_  ( level   )
        , context_( context )
    {}

    template<class T, class... U>
    void operator()( const T &  t, U&&...  u )
    {
        std::string  fmt = std::string( "[{}] " ) + t;
        logger_.log(
            level_,
            fmt.c_str(),
            context_.name(),
            std::forward<U>( u )... );
    }

private:
    spdlog::logger &           logger_;
    spdlog::level::level_enum  level_;
    const log_context &        context_;
};

} // namespace logging

#define LOGGER ::logging::instance()

#define CHECK_LEVEL( level_name ) \
    LOGGER.should_log( ::spdlog::level::level_name )

#define CHECK_AND_LOG( level_name )      \
    if ( !CHECK_LEVEL( level_name ) ) {} \
    else                                 \
        ::logging::log_statement(        \
            LOGGER,                      \
            ::spdlog::level::level_name, \
            __log_context__::context() )

#define LOG_TRACE CHECK_AND_LOG( trace )
#define LOG_DEBUG CHECK_AND_LOG( debug )
#define LOG_INFO CHECK_AND_LOG( info )
#define LOG_WARNING CHECK_AND_LOG( warn )
#define LOG_ERROR CHECK_AND_LOG( err )
#define LOG_CRITICAL CHECK_AND_LOG( critical )

#define LOG_CONTEXT( name_ )                        \
    struct __log_context__                          \
    {                                               \
        static ::logging::log_context context()     \
        {                                           \
            return ::logging::log_context( name_ ); \
        }                                           \
    }

LOG_CONTEXT( "global" );

我陷入困境的是构建在定义最内层__log_context__时要使用的上下文堆栈。我们可以使用不同名称的结构和宏约定来添加1或2个级别(例如LOG_MODULE可以定义__log_module__),但我想要一个更通用的解决方案。以下是我可以想到的使事情变得更容易的限制:

  1. 范围嵌套级别可以合理限制,但用户不必提供当前级别/代码可以移动到不同的范围而不进行更改。也许16级就足够了(这给了我们orgname :: app :: module :: subsystem :: subsubsystem :: detail :: impl :: detail :: util,还有一些空间......)
  2. 范围内的下一级范围(在单个翻译单元中)的数量可能是有界的,但应该远大于1的值。也许256是合理的,但我确信有人会有一个反例。
  3. 理想情况下,相同的宏可以用于任何上下文。
  4. 我考虑过以下方法:

    1. using __parent_context__ = __log_context__; struct __log_context__ ...

      希望__parent_context__获取外部上下文,但我收到编译器错误,指示类型名称必须明确地引用同一范围内的单个类型。此限制仅适用于在类的主体中使用,否则这将适用于函数和名称空间。

    2. 跟踪适用于范围的结构,例如boost::mpl::vector

      本教程中的示例让我相信我会遇到与1中相同的问题,因为被推送到后的向量需要被赋予一个独特的名称,需要在嵌套的作用域中专门引用。 / p>

    3. 使用预处理程序计数器生成适用的外部作用域的名称。

      这可以在我上面的简单用法示例中使用,但是在命名空间中存在不连续声明或相应类之外的方法定义时会失败。

    4. 如何在嵌套作用域中访问此信息?

2 个答案:

答案 0 :(得分:2)

好的,我找到了解决方案。

诀窍在于外部作用域中可见的decltype(var) var将解析为该外部作用域var的类型,即使我们稍后定义var相同的范围。这允许我们通过外部类型的其他未使用的变量来遮蔽外部类型但仍然访问它,同时允许我们定义要在内部作用域中访问的同名变量。

我们的一般建筑看起来像

struct __log_context__
{
    typedef decltype(__log_context_var__) prev;
    static const char * name() { return name_; }
    static ::logging::log_context  context()
    {
        return ::logging::log_context(
            name(), chain<__log_context__>::get() );
    }
};
static __log_context__ __log_context_var__;

唯一的另一个细节是我们在迭代上下文链时需要一个终止条件,因此我们使用void*作为sentinel值,并在用于构造输出字符串的辅助类中专门用它。

decltype需要C ++ 11,并允许将本地类传递给模板参数。

#include <spdlog/spdlog.h>

namespace logging {

spdlog::logger & instance()
{
    auto sink =
        std::make_shared<spdlog::sinks::ansicolor_stdout_sink_mt>();
    decltype(sink) sinks[] = {sink};
    static spdlog::logger logger(
        "console", std::begin( sinks ), std::end( sinks ) );
    return logger;
}

class log_context
{
public:
    log_context( const char *         name,
                 const std::string &  scope_name )
        : name_ ( name       )
        , scope_( scope_name )
    {}

    const char * name() const
    { return name_; }

    const char * scope() const
    { return scope_.c_str(); }

private:
    const char *  name_;
    std::string   scope_;
};

class log_statement
{
public:
    log_statement( spdlog::logger &           logger,
                   spdlog::level::level_enum  level,
                   const log_context &        context )
        : logger_ ( logger  )
        , level_  ( level   )
        , context_( context )
    {}

    template<class T, class... U>
    void operator()( const T &  t, U&&...  u )
    {
        std::string  fmt = std::string( "[{}] " ) + t;
        logger_.log(
            level_,
            fmt.c_str(),
            context_.scope(),
            std::forward<U>( u )... );
    }

private:
    spdlog::logger &           logger_;
    spdlog::level::level_enum  level_;
    const log_context &        context_;
};

} // namespace logging

// Helpers for walking up the lexical scope chain.
template<class T, class Prev = typename T::prev>
struct chain
{
    static std::string get()
    {
        return (chain<Prev, typename Prev::prev>::get() + ".")
            + T::name();
    }
};

template<class T>
struct chain<T, void*>
{
    static std::string get()
    {
        return T::name();
    }
};

#define LOGGER ::logging::instance()

#define CHECK_LEVEL( level_name ) \
    LOGGER.should_log( ::spdlog::level::level_name )

#define CHECK_AND_LOG( level_name )      \
    if ( !CHECK_LEVEL( level_name ) ) {} \
    else                                 \
        ::logging::log_statement(        \
            LOGGER,                      \
            ::spdlog::level::level_name, \
            __log_context__::context() )

#define LOG_TRACE CHECK_AND_LOG( trace )
#define LOG_DEBUG CHECK_AND_LOG( debug )
#define LOG_INFO CHECK_AND_LOG( info )
#define LOG_WARNING CHECK_AND_LOG( warn )
#define LOG_ERROR CHECK_AND_LOG( err )
#define LOG_CRITICAL CHECK_AND_LOG( critical )

#define LOG_CONTEXT_IMPL(prev_type,name_)            \
struct __log_context__                               \
{                                                    \
    typedef prev_type prev;                          \
    static const char * name() { return name_; }     \
    static ::logging::log_context  context()         \
    {                                                \
        return ::logging::log_context(               \
            name(), chain<__log_context__>::get() ); \
    }                                                \
};                                                   \
static __log_context__ __log_context_var__

#define LOG_CONTEXT(name_) \
    LOG_CONTEXT_IMPL(decltype(__log_context_var__),name_)

#define ROOT_CONTEXT(name_) \
    LOG_CONTEXT_IMPL(void*,name_)

// We include the root definition here to ensure that
// __log_context_var__ is always defined for any uses of
// LOG_CONTEXT.
ROOT_CONTEXT( "global" );

与我的初始帖子中的代码近似

#include <logging.hpp>

namespace app {

LOG_CONTEXT( "app" );

class Connector {
    LOG_CONTEXT( "Connector" );

public:
    void send( const std::string &  msg )
    {
        LOG_CONTEXT( "send()" );
        LOG_TRACE( msg );
    }
};

} // namespace app

void fn()
{
    LOG_DEBUG( "in fn" );
}

int main()
{
    LOG_CONTEXT( "main()" );
    LOGGER.set_level( spdlog::level::trace );
    LOG_INFO( "starting app" );
    fn();
    app::Connector c;
    c.send( "hello world" );
}

产量

[2018-03-22 22:35:06.746] [console] [info] [global.main()] starting app
[2018-03-22 22:35:06.747] [console] [debug] [global] in fn
[2018-03-22 22:35:06.747] [console] [trace] [global.app.Connector.send()] hello world

根据需要。

有条件地继承问题示例中提到的外部范围,这是一个练习。

答案 1 :(得分:0)

写一个例子需要一些时间,但我将分享我如何解决这个问题。

  • 您的LOG_CONTEXT可以在任何地方调用,因此如果我们创建多个静态对象,那么它们的构造顺序是未知的。
  • 您的上下文可以按行号排序,可以使用__LINE__
  • 访问
  • LOG_CONTEXT可以创建LoggingContext struct的静态对象,该对象在创建时自行注册到本地容器。 (通过本地我的意思是在编译对象中是唯一的,可以使用匿名命名空间实现)
  • LOG_*应该使用当前行并从本地寄存器中获取最新的LoggingContext。 (或者,如果需要的话,最后几个)
  • 我认为所有这些都可以通过constexpr sematics(但非常挑剔)

打开问题:

  • 函数中的静态对象(在第一次调用中创建)
  • 上下文的嵌套(可能比较__FUNCTION__会起作用吗?)

PS。我会试着在周末实施它