概述

_LINE_和_FILE_是C/C++中的预定义宏，分别用于获取当前代码所在的行号和文件名。本文详细讲述了它们的使用场景和使用方法，消除了一些陈旧错误的理解，重点实践了它们在软件调试、系统异常处理过程中举足轻重的作用。
编译器在预处理阶段将它们替换为相应的值，具体来说：_LINE_宏会被替换为当前代码所在的行号，表示该行号在源文件中的位置；_FILE_宏会被替换为当前代码所在的文件名，表示包含该代码的源文件的文件名。通过在日志记录或错误消息中使用_LINE_宏，可以动态地获取代码中出现问题的位置，并将其包含在日志或错误消息中，以帮助开发人员在调试和错误处理中排查问题。要再次强调的是，这些宏的值是在编译时确定的，因此它们提供的行号和文件名是编译时的信息，而不是运行时的信息。

转载请标明原文链接，
https://blog.csdn.net/quguanxin/category_6223029.html

痛点分析

#define STRINGIFY(x) #x          //it won't take effect, if you just do this
#define TOSTRING(x) STRINGIFY(x) //it works
//
std::string generateErrorMessage(std::string msg) {
    return msg + " in " + __FILE__ + " at line " + /*std::to_string(__LINE__)*/ TOSTRING(__LINE__);
}
//
int main() {
    std::string errorMsg = generateErrorMessage("Something went wrong.");
    std::cout << errorMsg.c_str() << std::endl;
    system("pause"); return 0;
}

执行结果，

如上，我们期望标记的是第13行代码位置，而运行结果却只能是 LINE 出现的第9行代码。FILE 存在相似的情况。

LINE 代码所在行号

早些年由于对_LINE_宏的不够了解，以为，既然它是编译时确定的，那么就只能死板的在待调试行上写包含_LINE_宏的代码，而不能封装或传递它。而实际上，配合宏函数的使用或者将其作为size_t 类型的函数实参，可以非常灵活的使用它。_LINE_宏可以直接转为字符串、可以作为int类型使用、也可以封装在宏函数内部（最终客户端调用宏函数，LINE 被转换为宏函数所在的行），接下来我们展开论证。

LINE 直接转为字符串

#include <iostream>
#include <string>

#define STRINGIFY(x) #x          //it won't take effect, if you just do this
#define TOSTRING(x) STRINGIFY(x) //it works

// 定义一个宏来生成带有错误消息、文件名和行号的字符串
#define ERROR_MSG(msg) ("Error: " + std::string(msg) + " in " + __FILE__ + " at line " + TOSTRING(__LINE__))

int main() {
    std::string errorMsg = ERROR_MSG("Something went wrong.");
    std::cout << errorMsg << std::endl;
    return 0;
}

（操作符#）是C/C++中的预处理器操作符，称为字符串化操作符（stringify operator）。在预处理阶段，它可以将宏参数或标识符转换为字符串常量。具体来说，#操作符会在宏展开过程中将其后面的标识符或参数转换为一个以双引号括起来的字符串。

LINE 作为整型数据使用

我们以 ros2/rcutils/error_handling.h中的函数为例，

/// Set the error message, as well as the file and line on which it occurred.
/**
 * This is not meant to be used directly, but instead via the
 * RCUTILS_SET_ERROR_MSG(msg) macro.
 *
 * The error_msg parameter is copied into the internal error storage and must
 * be null terminated.
 * The file parameter is copied into the internal error storage and must
 * be null terminated.
 *
 * \param[in] error_string The error message to set.
 * \param[in] file The path to the file in which the error occurred.
 * \param[in] line_number The line number on which the error occurred.
 */
RCUTILS_PUBLIC void rcutils_set_error_state(const char * error_string, const char * file, size_t line_number);

/// Set the error message, as well as append the current file and line number.
/**
 * If an error message was previously set, and rcutils_reset_error() was not called
 * afterwards, and this library was built with RCUTILS_REPORT_ERROR_HANDLING_ERRORS
 * turned on, then the previously set error message will be printed to stderr.
 * Error state storage is thread local and so all error related functions are
 * also thread local.
 *
 * \param[in] msg The error message to be set.
 */
#define RCUTILS_SET_ERROR_MSG(msg) \
  do {rcutils_set_error_state(msg, __FILE__, __LINE__);} while (0)

如上，首先在编译预处理阶段，LINE 被替换为 RCUTILS_SET_ERROR_MSG 宏函数的代码行号，然后其作为一个整型数据，也即作为 rcutils_set_error_state 函数 line_number 参数的实参被传递。接下来我们定义一个简单的可接收 _FILE_, __LINE__实参的函数，

//形参类型分别对应 const char* 和 size_t 
std::string generateErrorMessage(std::string msg, const char* file, size_t line_no) {
    return msg + " in " + file + " at line " + std::to_string(line_no);
}
//
int main() {
    std::string errorMsg = generateErrorMessage("Something went wrong.", __FILE__, __LINE__);
    std::cout << errorMsg << std::endl;
    system("pause");  return 0;
}

执行结果如上，LINE 被识别为其出现位置所在的行号。这种方案很好理解，但在实际使用中每次都要去传递 FILE 和 LINE 数据，让人感觉不是很舒服。一种更高级的办法是，将上述 generateErrorMessage 用宏函数封装。具体我们看下一小节。

_LINE_标记宏函数的调用位置

一个应对策略就是，定义宏函数，

//
#define ERROR_MSG(errorMsg, msg) \
{ \
    errorMsg = generateErrorMessage("Error:" + std::string(msg), __FILE__, __LINE__); \
}  \
//一种更优雅的写法是
#define ERROR_MSG(errorMsg, msg) \
do { errorMsg = generateErrorMessage("Error:" + std::string(msg), __FILE__, __LINE__); } while (0) 

C/C++语法要求在宏展开时，宏展开的结果必须是一个完整的语句。故在使用宏定义时，通常使用do {…} while(0)的技巧可以确保宏的语法完整性，使其在被展开时能够像代码块一样使用，且可以避免语法错误，提高代码可读性。当然，你也可以仅使用花括号。

测试结果如下，

如上测试结果表明，ERROR_MSG函数中无论_LINE_出现在其中的第几行，都无关紧要，_LINE_标记的是 ERROR_MSG 宏的调用位置（如上图行号为27行），而不是 _LINE_标记的直接位置 （如上图行号22行）。至此，算是消除了对 _LINE_的一个大误会，它的使用方法，远比我之前以为的要灵活。

FILE 代码所在文件名

在前文讲述 LINE 宏的过程中，也同时完成了 FILE 宏的使用实践，它是一个字符串常量，表示当前源文件的文件名，包括文件的路径，其对应的数据类型是 const char* ，也即 C 语言字符串。

简单实验

#include <stdio.h>
#include <iostream>
//
int main() {
    printf("当前源文件名：%s\n", __FILE__);
    system("pause");  return 0;
}

如上，输出 FILE 所在的代码文件的全路径。当资源很紧张，或者文件路径较深的时候，全路径名就会很烦人，咋办？

不期望 FILE 宏代表全路径

如上一小节，在Windows上使用 _FILE_ 宏，默认情况下其代表的是源代码文件的全路径名称，但在大多情况下，这会显得有点冗余、浪费资源。一般情况在同一个项目下，存在同名文件的可能性不大，同名且内容相同的可能更是不存在，因此我们仅保留文件名就可以。为此我们对 _FILE_ 宏进行如下重定义，

#ifdef _WIN32
#define FILE_NAME (strrchr(__FILE__, '\\') ? strrchr(__FILE__, '\\') + 1 : __FILE__)
#else
#define FILE_NAME (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__)
#endif

定义一个名为FILE_NAME的宏，它使用strrchr函数来查找最后一个斜杠字符’/'，并返回该字符后面的字符串部分。如果没有斜杠字符，则直接返回__FILE__宏的值。要注意的是，在不同操作系统上，文件路径使用不同的分隔符。对比效果如下，清澈了许多，

测试用的源代码如下，

#include <stdio.h>
#include <iostream>
//
#ifdef _WIN32
#define FILE_NAME (strrchr(__FILE__, '\\') ? strrchr(__FILE__, '\\') + 1 : __FILE__)
#else
#define FILE_NAME (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__)
#endif
//
int main() {
    printf("当前源文件名：%s\n", FILE_NAME);
    system("pause"); return 0;
}

assert 使用了 FILE 和 LINE

int main() {
    printf("当前源文件名：%s, 当前代码行号：%s\n", FILE_NAME, __LINE__);
    assert(0 == 1);
    system("pause"); return 0;
}

通过上述测试，可以猜测，assert 内部极有可能是封装了 FILE 和 LINE 预处理宏的。看一下源码，

#ifdef NDEBUG
    #define assert(expression) ((void)0)
#else
    _ACRTIMP void __cdecl _wassert(
        _In_z_ wchar_t const* _Message,
        _In_z_ wchar_t const* _File,
        _In_   unsigned       _Line
        );

    #define assert(expression) (void)(                                                       \
            (!!(expression)) ||                                                              \
            (_wassert(_CRT_WIDE(#expression), _CRT_WIDE(__FILE__), (unsigned)(__LINE__)), 0) \
        )
#endif

与我们前面自定义函数的使用方法一致，先以 char* 和 int 为参数类型，定义函数，然后，使用宏封装此函数，这样，LINE 和 FILE 就可以用来代表宏函数(assert) 的调用位置。

借助TLS技术

参见 src/error_handling.c 中的实现，定义线程本地存储TLS变量，

// g_ is to global variable, as gtls_ is to global thread-local storage variable
RCUTILS_THREAD_LOCAL bool gtls_rcutils_thread_local_initialized = false;
RCUTILS_THREAD_LOCAL rcutils_error_state_t gtls_rcutils_error_state;
RCUTILS_THREAD_LOCAL bool gtls_rcutils_error_string_is_formatted = false;
RCUTILS_THREAD_LOCAL rcutils_error_string_t gtls_rcutils_error_string;
RCUTILS_THREAD_LOCAL bool gtls_rcutils_error_is_set = false;

到这里就有点偏了… 已经超出了这个小主题… 跑到错误处理中了…

小结

在《异常处理/分析ROS2异常处理的设计和实现思路》（尚未发布）一文中，有提到过，针对调试信息，越直接越好，而 LINE 与 FILE 宏所表现出来的，几乎就是最直接的。
站在开发者的角度上，无论是何种形式的异常处理，都是手段，我们根本目的始终是快速定位程序运行过程中的问题，并尽力地使其从问题中恢复正常运行。不同于此的，用户角度，作为软件的使用者，用户希望看到的告警信息应该是，可读性强、及时性好、清晰明了、具体详细的，并且好的告警信息不仅指出问题，还应该提供解决方案或建议，是可以操作和控制的。用户绝对不希望看到晦涩难懂的告警信息，而是希望能够快速地理解问题所在，因此给用户的告警信息必须是能简练和准确描述问题本质和原因的。虽说是具体详细，但也绝不是详细到哪个代码行，这是很容易理解的。用户期望了解的问题的具体细节，应该是业务层级的，操作层级的，而不是系统实现层级。