如何在 C++ 中的嵌套词法作用域可访问的作用域中声明静态信息?
How to declare static information in scopes accessible to nested lexical scopes in C++?
我想为范围声明标识符,这些标识符将用于自动填充最内部范围内的任何日志记录语句的字段。它们通常但不总是(例如 lambdas,用 {}
引入的块)匹配封闭块的 "name"。
用法看起来像这样:
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__
),但我想要一个更通用的解决方案。以下是我能想到的使事情变得更容易的限制:
- 作用域嵌套级别可以合理限制,但用户不必提供当前 level/code 可以移动到不同的作用域而无需更改。也许 16 个级别就足够了(这给了我们 orgname::app::module::subsystem::subsubsystem::detail::impl::detail::util 一些空闲空间...)
- 范围内(在单个翻译单元中)下一级范围的数量可能是有限的,但应该比 1 的值大得多。也许 256 是合理的,但我相信有人会有反例.
- 理想情况下,同一个宏可用于任何上下文。
我考虑过以下方法:
using __parent_context__ = __log_context__; struct __log_context__ ...
希望 __parent_context__
获取外部上下文,但我收到编译器错误,指示类型名称必须明确引用同一范围内的单个类型。此限制仅适用于 class 的主体,否则将适用于函数和名称空间。
跟踪适用于范围的结构,例如 boost::mpl::vector
本教程中的示例让我相信我会 运行 遇到与 1 中相同的问题,因为被推送到之后的向量需要被赋予一个不同的名称,这将需要被引用特别是在嵌套范围内。
正在使用预处理器计数器生成适用的外部作用域的名称。
这在我上面的简单用法示例中会起作用,但如果命名空间中存在不连续的声明或相应 class.
之外的方法定义,则会失败
如何在嵌套范围内访问此信息?
写一个例子需要一些时间,但我会分享我是如何解决这个问题的。
- 你的
LOG_CONTEXT
可以在任何地方调用,所以如果我们创建多个静态对象,那么它们的构造顺序是未知的。
- 您的上下文可以按行号排序,可通过
__LINE__
访问
LOG_CONTEXT
可以创建 LoggingContext
结构的静态对象,self-registers 到正在创建的本地容器。 (本地是指在编译对象中唯一,可以通过匿名命名空间实现)
LOG_*
应该使用当前行并从本地寄存器中获取最新的 LoggingContext。 (如果需要的话,最后几个)
- 我认为所有这些都可以通过
constexpr
语义学(但相当大的挑战)
未解决的问题:
- 函数中的静态对象(在第一次调用时创建)
- 上下文嵌套(也许比较
__FUNCTION__
可行)?
PS。我会尽量在周末实现它
好的,我找到了解决方案。
诀窍是在外部范围内可见的 var
的 decltype(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*
作为标记值,并在用于构建的助手 类 中专门针对它输出字符串。
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" );
这与我最初 post
中的代码近似
#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
随心所欲。
问题示例中提到的有条件地继承外部作用域留作练习。
我想为范围声明标识符,这些标识符将用于自动填充最内部范围内的任何日志记录语句的字段。它们通常但不总是(例如 lambdas,用 {}
引入的块)匹配封闭块的 "name"。
用法看起来像这样:
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__
),但我想要一个更通用的解决方案。以下是我能想到的使事情变得更容易的限制:
- 作用域嵌套级别可以合理限制,但用户不必提供当前 level/code 可以移动到不同的作用域而无需更改。也许 16 个级别就足够了(这给了我们 orgname::app::module::subsystem::subsubsystem::detail::impl::detail::util 一些空闲空间...)
- 范围内(在单个翻译单元中)下一级范围的数量可能是有限的,但应该比 1 的值大得多。也许 256 是合理的,但我相信有人会有反例.
- 理想情况下,同一个宏可用于任何上下文。
我考虑过以下方法:
using __parent_context__ = __log_context__; struct __log_context__ ...
希望
__parent_context__
获取外部上下文,但我收到编译器错误,指示类型名称必须明确引用同一范围内的单个类型。此限制仅适用于 class 的主体,否则将适用于函数和名称空间。跟踪适用于范围的结构,例如
boost::mpl::vector
本教程中的示例让我相信我会 运行 遇到与 1 中相同的问题,因为被推送到之后的向量需要被赋予一个不同的名称,这将需要被引用特别是在嵌套范围内。
正在使用预处理器计数器生成适用的外部作用域的名称。
这在我上面的简单用法示例中会起作用,但如果命名空间中存在不连续的声明或相应 class.
之外的方法定义,则会失败
如何在嵌套范围内访问此信息?
写一个例子需要一些时间,但我会分享我是如何解决这个问题的。
- 你的
LOG_CONTEXT
可以在任何地方调用,所以如果我们创建多个静态对象,那么它们的构造顺序是未知的。 - 您的上下文可以按行号排序,可通过
__LINE__
访问
LOG_CONTEXT
可以创建LoggingContext
结构的静态对象,self-registers 到正在创建的本地容器。 (本地是指在编译对象中唯一,可以通过匿名命名空间实现)LOG_*
应该使用当前行并从本地寄存器中获取最新的 LoggingContext。 (如果需要的话,最后几个)- 我认为所有这些都可以通过
constexpr
语义学(但相当大的挑战)
未解决的问题:
- 函数中的静态对象(在第一次调用时创建)
- 上下文嵌套(也许比较
__FUNCTION__
可行)?
PS。我会尽量在周末实现它
好的,我找到了解决方案。
诀窍是在外部范围内可见的 var
的 decltype(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*
作为标记值,并在用于构建的助手 类 中专门针对它输出字符串。
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" );
这与我最初 post
中的代码近似#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
随心所欲。
问题示例中提到的有条件地继承外部作用域留作练习。