std::source_location 不能直接提供可读函数签名，其 function_name() 返回编译器生成的 mangled 名（如 "_Z12my_functionv"），需手动调用 abi::__cxa_demangle（Linux/macOS）或 UnDecorateSymbolName（Windows）解码，且存在内存管理与平台兼容性问题；release 构建中该字段内容不可靠，推荐使用 PRETTY_FUNCTION 或 FUNCSIG 等编译器扩展替代。
std::source_location 是什么，它能给你函数签名吗
std::source_location 是 C++20 引入的轻量结构体，用于在编译期捕获调用点的文件名、行号、列号和函数名。但它返回的 function_name() 是**编译器生成的符号名（mangled name）**，不是你写的可读函数签名，比如可能是 "_Z12my_functionv" 而非 "void my_function()"。
如何把 mangled name 解析成可读签名（Linux/macOS）
需要调用 abi::__cxa_demangle 手动解码，且必须自己管理内存。常见错误是忽略返回值检查或未释放缓冲区：
-
abi::__cxa_demangle返回char*，成功时需用free()释放；失败时返回nullptr - 不能直接用
std::string构造临时char*，否则悬垂指针 - MSVC 不支持
abi::__cxa_demangle，Windows 下需换用UnDecorateSymbolName（需dbghelp.h）
#include <iostream>
#include <string>
#include <cstdlib>
#include <memory>
#include <cxxabi.h>
<p>std::string demangle(const char<em> mangled) {
int status = 0;
std::unique_ptr<char, void(</em>)(void*)> res{
abi::__cxa_demangle(mangled, nullptr, nullptr, &status),
std::free
};
return (status == 0) ? res.get() : mangled;
}</p><p>void log_call(std::source_location loc = std::source_location::current()) {
std::cout << demangle(loc.function_name())
<< " @ " << loc.file_name()
<< ":" << loc.line() << "\n";
}</p>为什么不要在 release 构建中依赖 function_name()
std::source_location::function_name() 的内容由编译器决定：GCC/Clang 默认提供 mangled 名，但启用 -fno-rtti 或某些 LTO 优化后可能为空字符串；MSVC 在 /O2 下也可能省略。它不保证稳定，也不受标准约束 —— 标准只要求“实现定义的字符串”，所以：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不能用于日志归档或跨版本比对
- 调试宏里用可以，但别写进核心逻辑分支判断
- 若需可靠函数标识，应配合宏拼接（如
__PRETTY_FUNCTION__）或自定义注册表
更简单可靠的替代方案（C++20 前后都可用）
如果目标只是“快速看一眼当前函数在哪被调”，__PRETTY_FUNCTION__（GCC/Clang）或 __FUNCSIG__（MSVC）更直接，无需解码，也无运行时开销：
立即学习“C++免费学习笔记（深入）”；
#define LOG_HERE() \
do { \
std::cout << __PRETTY_FUNCTION__ << " (" \
<< __FILE__ << ":" << __LINE__ << ")\n"; \
} while(0)
注意：__PRETTY_FUNCTION__ 不是标准特性，但所有主流编译器都支持；而 std::source_location 虽然标准，但它的 function_name() 字段目前几乎没有编译器输出可读签名 —— 这个事实容易被文档误导。
