我想知道当 included 或 includee 仅作为软链接(soft link)位于同一目录时，引用的包含会发生什么情况。
想象一下三个 header ，a、b 和c，以及一个目录d。 a 和 b 在 CWD 中，c 在 d 下。现在想象一下 d 下的一个软链接(soft link)指向 b(名为 b)。
如果只使用引用的包含并且c包含b，其中包含a，是否会搜索a在目录d 中，这是到b 的软链接(soft link)的位置，还是在CWD 中的b 的实际物理位置？
我读过 a page at MSDN但我找不到明确的答案。 “与包含#include 语句的文件相同的目录”是什么意思？
最佳答案
解决软链接(soft link)的机制不考虑当前工作目录，而是解决链接所在的目录。让我用一个更自然的例子来演示，如果你试着阅读 /usr/include/X11/Xlib.h (例如，这是编译器将在 Linux 中搜索 <X11/Xlib.h> 的地方之一)并且碰巧 /usr/include/X11是到 ../../opt/X11/include 的软链接(soft link), 算法解析为 /usr/include/../../opt/X11/include (或者实际上 /opt/X11/include 最后，在解决所有路径组件之后)，独立于您的当前目录。当前或根目录是在您的 u 区(专用于您的进程的操作系统资源的一部分)中保留的 inode 表条目，以便启动机制或将名称解析为 inode 条目任务，最终处理 inode您要打开的文件。这对编译器来说是透明的，所以尽管有人说它是实现定义的，但碰巧所有 posix 系统都有一个简单的机制来搜索系统相关的目录列表以查找最终文件。但是软链接(soft link)机制是透明的，您不需要期待特殊的编译器行为。
编译器唯一会考虑其当前工作目录的情况是，如果您真的强制它这样做，如:
#include "./header.h"
或
#include "../../includes/myprojectheader.h"
编辑
如果软链接(soft link)指向一个文件(而不是一个目录)，如本例所示:
假设您的安装已将 ncurses 包含在一个子目录中(比方说 ncurses )在 /usr/include 中, 而您想使用 #include <ncurses.h> , 所以你安排了以下内容:
ln -s ncurses/curses.h curses.h
您将获得指向文件 /usr/include/curses.h 的链接指向ncurses/curses.h然后当你打开/usr/include/curses.h内核到达路径的最后一部分(curses.h)并发现它是一个符号链接(symbolic link)，因此它替换最后一部分(因为指向的链接不是绝对的)并将其替换为ncurses/curses.h。 , 并打开文件 /usr/include/ncurses/curses.h .
关于c++ - include 如何使用软链接(soft link)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49557565/