包含头文件时，路径是否区分大小写？答案

【问题标题】：When including header files, is the path case sensitive?包含头文件时，路径是否区分大小写？
【发布时间】：2010-12-29 10:42:38
【问题描述】：

鉴于此目录树：

src/MyLibrary/MyHeader.h
src/file.cpp

file.cpp:

#include "mylibrary/myheader.h"
...

编译 file.cpp 与 VS 一起工作，在 gcc 中失败。

标准是怎么说的？
如果路径区分大小写，为什么这样做是明智的？
最佳做法是什么，将所有文件/文件夹名称保持小写，因此在包含时也这样做？

谢谢。

【问题讨论】：

标签： c++ windows visual-studio linux gcc

【解决方案1】：

它不是 C++ 标准，它是 Linux 方式，所有路径名都区分大小写。最好的做法是选择你想要的任何文件名（大多是小写）并在 include 指令中使用相同的大小写。也总是使用相对文件路径。

【讨论】：

恐怕你错了。是控制这一点的 C++ 标准，并允许任何实现按照它认为合适的方式执行搜索。

【解决方案2】：

区分大小写取决于操作系统。 Windows 不区分大小写。 Linux 是。

编辑：

实际上，正如Martin York 的评论所观察到的，区分大小写取决于文件系统。默认情况下，Windows 使用不区分大小写的文件系统，而 Linux 使用区分大小写的文件系统。对于有兴趣了解哪些文件系统区分大小写以及哪些不区分大小写的人，维基百科上有一个完整的列表：Comparison of file name limitations。

【讨论】：

实际上它更多地与使用的文件系统相关，而不是操作系统。默认值如上定义。但在 Linux 上，有更多种类的文件系统可供选择，其中一些不区分大小写。
@Martin：是的，你是对的。感谢您的准确观察。
所以 C89/99/++11 没有指定区分大小写？还是标准说搜索路径和文件名不区分大小写？
不，抱歉，它既不是操作系统也不是文件系统，正如my answer 中所述。
甚至关于文件系统区分大小写的评论也是错误的。 Windows 主要使用 NTFS。 NTFS 区分大小写。 Windows API 中的 I/O 实现不区分大小写。

【解决方案3】：

要记住的另一点是路径分隔符。尽管 Visual Studio（以及我确定的其他 Windows IDE）将接受“/”或“\”，但您应该始终在包含路径中使用“/”以实现可移植性。

【讨论】：

为了更好的可移植性，例如移动源文件，路径不应该在源代码中，而是提供给编译器。如果头文件移动，那么所有通过路径引用它们的代码都必须更改并进行回归测试！
@ThomasMatthews 我从来没有想到过。那么如何在不使用它们各自的子文件夹的情况下包含标题呢？
@ThomasMatthews -- （我只花了 9 年的时间来解决这个问题） -- 我 25,000% 同意这一点，并提倡你在我自己的工作中专门提到的方法......我只是在解决问题，但错过了“真正”用更好的建议回答问题的机会。赞一个！

【解决方案4】：

标准是怎么说的？

#include 指令中的大小写敏感性由实现（编译器/预处理器）控制。这在 16.2.2 [cpp.include] 下进行了解释：

形式为
# include < h-char-sequence> new-line
的预处理指令在一系列实现定义的位置中搜索由< 和> 分隔符之间的指定序列唯一标识的标头，并用标头的全部内容替换该指令。 如何指定位置或标识的标头是实现定义的。

同样，16.2.3 [cpp.include]：

形式为
# include " q-char-sequence" new-line
的预处理指令导致将该指令替换为由" 分隔符之间的指定序列标识的源文件的全部内容。 以实现定义的方式搜索指定的源文件。如果不支持此搜索，或者搜索失败，则重新处理指令，就像它读取一样
# include < h-char-sequence> new-line
具有与原始指令相同的包含序列（包括> 字符，如果有的话）。

语言实现的自然选择是使用文件系统或操作系统的区分大小写，但没有严格要求这样做（正如所有其他答案所暗示的那样）。

最佳做法是什么，将所有文件/文件夹名称保持小写，因此在包含时也这样做？

一如既往的最佳做法：保持一致。如果您在项目中使用大小写混合的源/头文件，请继续使用它们并在您的 #include 指令中复制确切的大小写。

【讨论】：