在VC中，当使用/FC时，__FILE__展开为完整路径，不使用/FC选项__FILE__展开文件名。裁判:这里

Try

#pragma push_macro("__FILE__")
#define __FILE__ "foobar.c"

在源文件中的include语句之后，然后添加

#pragma pop_macro("__FILE__")

在源文件的末尾。

如果你使用CMAKE和GNU编译器，这个全局定义工作正常:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__MY_FILE__='\"$(notdir $(abspath $<))\"'")

在MSVC中，将FILENAME宏作为FILENAME=%(FILENAME)%(扩展名)添加到c++项目的预处理器定义中。恐怕这完全是一个编译器杀手。它在某种程度上打破了并行构建。

因为使用的是GCC，所以可以利用

__BASE_FILE__这个宏扩展为主输入文件的名称，以C字符串常量的形式。这是源文件 在预处理器或C编译器的命令行中指定

然后在编译时通过更改源文件表示(完整路径/相对路径/basename)来控制显示文件名的方式。

至少对于gcc， __FILE__的值是编译器命令行中指定的文件路径。如果你像这样编译file.c:

gcc -c /full/path/to/file.c

__FILE__将展开为“/full/path/to/file.c”。如果你这样做:

cd /full/path/to
gcc -c file.c

那么__FILE__将展开为“file.c”。

这可能是实际的，也可能不是。

C标准不要求这种行为。关于__FILE__，它只是将其扩展为“当前源文件的假定名称(字符串字面值)”。

另一种方法是使用#line指令。它覆盖当前行号，也可选择覆盖源文件名。如果你想覆盖文件名但保留行号，使用__LINE__宏。

例如，你可以把它添加到文件的顶部。c:

#line __LINE__ "file.c"

唯一的问题是它将指定的行号赋给下一行，而#line的第一个参数必须是一个数字序列，因此您不能执行类似的操作

#line (__LINE__-1) "file.c"  // This is invalid

确保#line指令中的文件名与文件的实际名称匹配作为练习。

至少对于gcc来说，这也会影响诊断消息中报告的文件名。