C++如何使用std::source_location在日志模块中自动注入函数名与行号-C++-PHP中文网

c++oding="utf-8" ?>

std::source_location不能直接拿到可读函数名，其function_name()返回编译器符号名或空字符串；应配合__func__获取函数名，用source_location获取文件名、行号和列号。

c++如何使用std::source_location在日志模块中自动注入函数名与行号

std::source_location 是什么，它能直接拿到函数名吗

std::source_location 是 C++20 引入的轻量结构体，用于在编译期捕获调用点的源码位置信息。它本身不存储函数名（function_name() 返回的是编译器生成的符号名，比如 "void log_info(const char*)" 或更糟的 "_Z8log_infoPKc"），但能稳定提供 file_name()、line()、column()。

所以别指望它“自动注入可读函数名”——你得靠宏 + __func__（或 __FUNCTION__）配合使用。

常见错误：直接写 std::source_location::current().function_name() 并期待得到 "main" 这样的干净名字，结果看到一堆乱码或空字符串（某些编译器/标准库实现返回空）。

std::source_location::current() 必须在被调用函数内部调用，不能提前取值再传参，否则位置信息指向宏展开处而非实际调用点
MSVC 和 GCC 12+ 支持较好；Clang 14+ 基本可用，但 function_name() 在 Clang 上常为空，务必实测
若需跨平台一致行为，函数名必须用 __func__，位置信息用 std::source_location

如何用宏把 func 和 std::source_location 组装进日志调用

核心思路：定义一个带默认参数的日志函数，让宏自动补全 __func__ 和 std::source_location::current()，避免每次手动传。

示例定义：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

void log_debug(const char* msg,
               const char* func = __func__,
               const std::source_location& loc = std::source_location::current()) {
    std::fprintf(stderr, "[%s:%d] %s — %s\n",
                 loc.file_name(), loc.line(),
                 func, msg);
}

调用时直接写 log_debug("user logged in")，无需传函数名或位置——宏不是必须的，但上面这种默认参数写法已足够简洁且无宏污染。

不要用 #define LOG_DEBUG(msg) log_debug(msg, __func__, std::source_location::current())：这会破坏调试栈（__func__ 变成宏名所在函数，不是调用者）
默认参数方式下，__func__ 展开在调用点，std::source_location::current() 也在调用点求值，行为可靠
注意：std::source_location 是 trivial 类型，按值传递零开销；__func__ 是静态字符串字面量，也不额外分配

为什么不能把 source_location 当作普通参数传给异步日志队列

如果你把日志异步化（比如 push 到线程安全队列里延后打印），std::source_location 里的 file_name() 返回的是 const char*，指向编译器内建的只读字符串字面量——它生命周期是整个程序运行期，没问题；但关键陷阱在于：__func__ 也是局部作用域的字符串字面量，同样安全。

真正危险的是：别在异步回调里用 std::source_location::current()！那会记录日志系统内部函数的位置，不是原始调用点。

必须在同步入口处（即用户调用日志函数那一刻）完成 std::source_location::current() 的求值，并把结果（含 file_name() 指针、line() 等）拷贝进日志消息结构体
不要存 std::source_location 的引用或指针，它不是 RAII 类型，只是几个整数和 const char* 字段
如果日志结构体需要长期持有文件名，确保不依赖 std::string 动态分配（小字符串优化可能不够快），多数场景直接存 const char* 就够了

GCC/Clang 下 function_name() 返回空字符串怎么办

这是真实存在的兼容性坑：Clang 默认不填充 function_name() 字段，GCC 12 开始支持但需开启 -g；即使有调试信息，libc++ 实现也可能返回空。

结论很明确：永远不要依赖 std::source_location::function_name() 做功能逻辑，它只是个“尽力而为”的提示字段。

坚持用 __func__ 获取函数名——它是 C++11 标准保证的，所有编译器都支持，内容可读
如果非要统一接口，可以封装一个辅助函数：
```
inline const char* safe_func_name(const std::source_location& loc) {
    auto fn = loc.function_name();
    return *fn ? fn : __func__;
}
```
但注意：这个 __func__ 在辅助函数里展开，返回的是辅助函数自己的名字，不是调用者——所以这写法无效。正确做法仍是让日志函数接收 const char* func = __func__
测试手段：在不同编译器下打印 loc.function_name() 内容，确认是否为空；CI 中建议加断言检查（仅 debug 模式）

最简、最稳的组合就是：__func__ 负责函数名，std::source_location 负责文件与行号，两者缺一不可，但职责分明。