历史：在C++20之前，开发人员依靠预处理器宏，如__FILE__和__LINE__来捕获源代码元数据以进行日志记录和调试。这些宏存在扩展上下文问题、命名空间污染，以及无法通过抽象层传播的缺陷，而不需要代码生成技巧。C++20标准引入了std::source_location，提供了一种类型安全、constexpr兼容的替代方案，能够自动捕获调用站点信息。
问题：在将日志记录功能封装在辅助函数中时，基于宏的方法捕获的是包装器定义的位置，而不是实际调用站点，这使得它们在深层调用栈中定位错误毫无用处。此外，通过每个函数签名手动传播源元数据会导致侵入性API更改和维护负担。需要一种机制来在调用点捕获文件名、行号、列和函数名而不需要显式参数传递。
解决方案：std::source_location是一个可以被编译器通过其静态成员函数current()实例化的简单可复制结构，具有私有构造函数。当作为函数参数的默认参数使用时，std::source_location::current()在调用站点进行评估，而不是在定义站点进行评估，利用编译器内在功能填充其字段以获取确切的源坐标。这一设计防止了手动构造任意源位置，确保了诊断的完整性，同时允许在模板实例化和回调链中无缝传播。
#include <source_location> #include <iostream> #include <string> class Logger { public: static void log(const std::string& message, std::source_location loc = std::source_location::current()) { std::cout << loc.file_name() << ":" << loc.line() << " [" << loc.function_name() << "] " << message << std::endl; } }; void process_data(int value) { if (value < 0) { Logger::log("接收到无效值"); // 捕获这一行，而不是Logger::log定义 } }
背景：一个高频交易系统需要分布式日志记录，错误报告必须准确定位源行位置，源代码行数达到数百万，包括模板算法和lambda回调。现有代码库使用基于宏的LOG_ERROR()扩展__FILE__和__LINE__，但当开发人员引入像validate_input()这样的辅助函数时，内部调用记录器，导致所有错误报告辅助函数内部行而不是业务逻辑调用站点。
问题：宏展开捕获的是在源代码中物理书写日志调用的位置，而不是逻辑错误的位置。当validate_input()在500个不同的地方被调用时，所有500个错误报告在验证函数内部相同的文件和行。这使得在竞争条件调查期间几乎无法进行生产调试。
考虑的解决方案：
选项 1：使用显式参数的宏传播。我们考虑强制每个函数接受const char* file, int line参数，通过变长宏包装器在每个调用站点注入这些参数。优点：在任意调用深度中保持准确的位置资料。缺点：大规模API污染，破坏第三方库接口，显著增加编译时间，且在constexpr上下文中无法使用宏。
选项 2：使用调试符号的运行时堆栈展开。实现使用平台特定API（如POSIX上的backtrace()或Windows上的CaptureStackBackTrace）捕获运行时堆栈跟踪，然后使用调试符号解析地址到行号。优点：对API不具侵入性，捕获完整调用堆栈。缺点：极大的运行时开销（不适合于高频路径），需要将调试符号传输到生产，且在崩溃条件下解析是不可靠的。
选项 3：带默认参数的std::source_location。用接受std::source_location loc = std::source_location::current()作为最后参数的函数替换宏。优点：零运行时开销（constexpr构建），通过模板的自动传播，捕获列信息以进行精确诊断，并且遵守命名空间范围没有污染。缺点：需要C++20编译器支持，开发人员必须记得将其放置为默认参数（而不是在函数体内，这样会捕获函数的内部位置）。
选择的解决方案和结果：我们选择了选项 3，因为交易系统正在迁移到C++20，std::source_location的constexpr特性允许在保持纳秒级性能要求的同时验证日志格式字符串。实现后，错误报告包含精确的行号，如trading_engine.cpp:847 [auto execute_order(const Order&)::(lambda)]，使我们能够在两小时内识别出关键的竞争条件，而不是两天。std::source_location不能手动构造的限制防止了初级开发人员在测试期间意外地传递伪造的位置，确保生产日志保持法医可信性。
为什么在作为默认参数使用时std::source_location::current()特殊，如果你在函数体内调用它会发生什么？
当std::source_location::current()作为默认参数出现时，C++20标准规定编译器在调用站点进行评估，替换为调用该函数的行。如果放置在函数体内，它将被评估为该特定行在函数定义中的位置，使其无用以归因于调用站点。这种行为是本语言规范中特定函数的特殊情况；常规默认参数在定义站点进行评估，但std::source_location则享有这种特殊处理以实现自动日志记录。初学者通常会将auto loc = std::source_location::current();放置为其日志函数的第一行，然后感到困惑，为什么每个日志条目都指向相同的内部行。
你能手动构造带有任意文件和行号的std::source_location吗，标准为什么防止这样做？
不，您不能手动构造有效的std::source_location，因为它的构造函数是私有的，只能由实现访问。标准执行此限制以维护诊断信息的完整性，防止开发人员在安全关键的日志系统中伪造源位置。虽然你可能想要在单元测试日志输出时模拟位置，标准委员会优先考虑法医可靠性而不是测试灵活性。获得实例的唯一方法是通过current()，这是作为编译器内在实现的，填充了结构的私有字段，使用实际翻译单元的内部表示。
std::source_location在lambda表达式、模板实例化和内联函数中是否正常工作，捕获了哪些特定元数据？
是的，std::source_location在所有这些上下文中都正确运行，但候选人常常忽略细节。对于lambda，function_name()返回实现定义的名称（通常是operator()或lambda的内部符号），而file_name()和line()指向源代码中的lambda定义位置。在模板实例化中，每个不同的实例会生成指向特定模板参数的源位置。该结构捕获四种元数据：file_name()（const char*）、line()（uint_least32_t）、column()（uint_least32_t，通常被低估但对宏重代码至关重要）和function_name()（const char*）。许多候选人不了解column()，它区分多个宏调用在同一物理行上，或者他们假设function_name()返回解码的符号（它实际上返回实现的原始函数签名）。