在我使用 C/C++ 的过程中，当将 .h 文件包含在 .cpp/.c 文件中时，我遇到了处理 #include 指令的文件路径的不同方法。谷歌风格指南暗示在你的#include 中使用部分文件路径。话虽如此，我目前正在从事一个项目（尽管是一个小项目），当我“继承”代码时，我为我布置了一个布局良好的 Makefile（用于 G++）和结构。即，有一个名为 /project_name 的目录，里面是 Makefile 和几个子目录。例如，/project_name/inc 保存 .h 文件，/project_name/src 保存 .cpp 文件。Makefile 设置为查看每个子目录以编译源代码。
我的问题是，鉴于目录结构和 Makefile，#include 的“首选”方法是什么。下面列出了我成功使用的两种替代方法。
我还有其他选择吗？
两者都不使用。相反，将所有公共标头放在具有单个根的某个层次结构中。例如，如果您的项目是 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 的更改，它是恒定的）。
这是一个主观的答案；如果两者都有效，那么两者都是正确的，但是我更喜欢不了解源代码中的源树，仅在项目设置/Makefile中，所以对我来说第一个选项是最好的：
#include "mycode.h"
正如 trojanfoe 所说，这是非常主观的，但我仍然会在下面采用这种风格。
#include "mycode.h"
如果根本需要重组具有 .cpp/.h 文件的文件夹，那么下面的样式就会变得脆弱并且注定会失败。您将被迫更改 .cpp 文件以提供正确的相对路径。
#include "../../project_name/inc/mycode.h" //
似乎在#include(ie option2) 中包含代码结构会使代码的可移植性降低。
我最近在将一个组件（用果酱构建）带到 cocoapod 以供 IOS 使用时遇到了问题。主要问题是代码中有以下代码
`#include <impl/xxxxx.h>`
当带入 cocoapods 时，它不会被编译，因为“impl”的路径未被识别，我没有找到它的设置。（我错了，只是分享我现在得到的）。改成
`#include "impl/xxxx.h" `
将使这个 pod 编译成功，但仍然不能用作客户端。sicne 客户端代码不知道“impl”结构。（如果公共接口没有这个结构包含，它会工作。但不是我的情况）
我最终删除了所有这些源结构，包括成为使用选项 1..
所以我的意思是。1) 对于公共标头，避免包含源结构。2）对于私有头/代码，使用“private/source/structure/xxxx.h”来轻松编译设置。
如果有什么请与我分享。