gcc：本地包含路径隐藏系统头文件

Question

我有一个本地文件endian.h，它声明了一些字节交换函数。

#pragma once
#include <cstdint>

inline uint16_t bswap(uint16_t val) { return __builtin_bswap16(val); }
inline uint32_t bswap(uint32_t val) { return __builtin_bswap32(val); }
...

似乎 CMake 在我的 makefile 中生成的包含路径导致 /usr/include/endian.h 对 /usr/include/ctype.h 隐藏，而不是解析为 ./src/foo/endian.h

In file included from /usr/include/ctype.h:39:0,
                 from /usr/include/c++/5/cctype:42,
                 ...
                 from ./src/foo/session.h:3

./endian.h: In function ‘uint32_t bswap(uint32_t)’:
./endian.h:17:36: error: conflicting declaration of C function ‘uint32_t bswap(uint32_t)’
  inline uint32_t bswap(uint32_t val) { return __builtin_bswap32(val); }

包含路径之一是当前目录，与我的endian.h 文件所在的目录相同：-I ./src/foo

正是这条路径导致/usr/include/endian.h被隐藏

作品：

g++ -I./src ./src/foo/session.cpp

破碎：

g++ -I./src -I./src/foo ./src/foo/session.cpp

我的印象是（明显错误的）尖括号包括搜索的系统路径，而quote包括搜索使用-I指定的路径。

使用包含路径-I./src，如果我来自./src/foo/foo.h 的#include "bar/bar.h"，即使它不是foo 子目录的本地（即：它使用-I./src 包含路径找到bar/bar.h )，我想这解释了我对每个包含类型含义的印象。

但是，这些似乎也会影响系统包含的查找方式（或者至少，尖括号包含的查找方式）。对吗？

在不强制我重命名本地 endian.h 文件的情况下，解决此问题的唯一方法是删除该包含路径吗？

Answer 1

这是 gcc 手册中关于包含搜索顺序的内容：

查找顺序如下：

1. 对于include指令的引用形式，首先搜索当前文件的目录。
2. 对于 include 指令的引用形式，由 -iquote 选项指定的目录按从左到右的顺序搜索，如 它们出现在命令行上。
3. 使用 -I 选项指定的目录按从左到右的顺序扫描。
4. 使用 -isystem 选项指定的目录按从左到右的顺序扫描。
5. 扫描标准系统目录。
6. 使用 -idirafter 选项指定的目录按从左到右的顺序扫描。

如您所见，-I 选项 (3) 包含的文件在标准系统目录 (5)（包括 /usr/include）之前搜索。

因此，一般而言，您使用-I 添加的目录中的文件将隐藏同名的系统标头，无论它们是否包含在<> 或"" 中。

"" 和<> 之间的区别在于"" 中包含的文件首先 搜索当前目录（以及-iquote 目录，但这更加模糊）。因此，如果您包含像#include "foo/bar.h" 这样的文件并且该文件包含“endian.h”，那么如果存在foo/endian.h，它将被使用，而不是标准包含目录中的同名文件。但是，如果您#include <endian.h> 将使用系统版本。这样一来，如果您使用正确的引用，在两个方向上都会减少意外的名称冲突。

Answer 2

最初"" 和<> 之间确实存在区别。但是，目前，据我所知，所有主要编译器都一视同仁。就编译器如何处理它们而言，它们之间确实没有区别。按照惯例，人们使用这些符号。 endian.h 是标准标头，通用名称。您可能应该将其向下移动一个文件夹以避免名称冲突，例如 "myProject/endian.h" 或将名称更改为更明确的名称。