在使用 C/C++ 的过程中，当将 .h 文件包含在 .cpp/.c 文件中时，我遇到了处理 #include 指令的文件路径的不同方法。 Google 风格指南暗示在 #include 中使用部分文件路径。话虽这么说，我目前正在从事一个项目（尽管是一个小项目），当我“继承”代码时，为我设计了一个精心设计的 Makefile（针对 G++）和结构。即有一个名为/project_name的目录，里面是Makefile和几个子目录。例如，/project_name/inc 保存 .h 文件，/project_name/src 保存 .cpp 文件。 Makefile 设置为查看每个子目录来编译源代码。
我的问题是，给定目录结构和 Makefile，#include 的“首选”方法是什么。下面列出了我成功使用的两种替代方案。
#include "mycode.h"#include "../../project_name/inc/mycode.h"我还缺少其他选项吗？
两者都不要使用。相反，将所有“public”标头放入具有单个根的某个层次结构中。例如，如果您的项目是 foo，请将所有公共标头放入 include/foo 中，但不要犹豫，将每个组件的标头分组：
include/foo/io/printer.hh
include/foo/io/reader.hh
include/foo/job/job.hh
include/foo/job/scheduler.hh
然后，如果您的代码仅使用
<foo/io/printer.hh>等，则需要您在项目构建期间传递正确的
-I $(top_srcdir)/include如果此外您还有私有标头，请使用相同的结构，但在另一个层次结构中，例如：
src/io/parser.hh
您可能会或可能不会决定使用
src/foo。不使用
src/foo但切勿使用相对路径。
如果明天项目目录的结构发生变化，您愿意修改一个 makefile 还是更改每一个自定义
#include以将更改考虑在内？
使用第二个选项将使目录结构的更改花费更多时间，并且适应所有内容所需的时间将随着项目大小而扩展（而对于 makefile 更改，它是恒定的）。
#include "mycode.h"
#include "mycode.h"
如果确实需要重构包含 .cpp/.h 文件的文件夹，那么下面的样式就会变得脆弱并且注定会失败。您将被迫更改 .cpp 文件以提供正确的相对路径。
#include "../../project_name/inc/mycode.h" //
我最近在将一个组件（用 Jam 构建）引入 cocoapod 以供 IOS 使用时遇到了问题。主要问题是代码中有以下代码
`#include <impl/xxxxx.h>`
当进入cocoapods时，它不会被编译，因为“impl”的路径没有被识别，而且我没有找到它的设置。（我错了，只是分享我现在得到的）。更改为
`#include "impl/xxxx.h" `
将使这个pod编译成功，但仍然不能被客户端使用。 sicne客户端代码不知道“impl”结构。（如果公共接口没有这个结构包含，它会工作。但它不是我的情况）
我最终删除了所有这些源结构，包括使用选项 1..
所以我的观点是。 1) 对于公共标头，避免包含源结构。 2) 对于私有头文件/代码，使用“private/source/struct/xxxx.h”以方便编译设置。
如果有什么请与我分享。