在我使用C / C ++时，在.cpp / .c文件中包含.h文件时，我遇到了处理#include指令文件路径的不同方法。 Google样式指南暗示在#include中使用部分文件路径。话虽这么说，我目前正在开发一个项目（尽管是一个小项目），当我“继承”代码时，我为我准备了一个精心布局的Makefile（用于G ++）和结构。也就是说，有一个名为/ project_name的目录，里面是Makefile和几个子目录。例如，/ project_name / inc包含.h文件，/ project_name / src包含.cpp文件。 Makefile设置为查看每个子目录以编译源代码。
我的问题是，给定目录结构和Makefile，＃include的“首选”方法是什么。我成功使用的两个备选方案如下所示。
我还缺少其他选项吗？
答案 0 :(得分：12)
两者都不使用。而是将所有 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的好处是更容易看到什么是公共标头和私有标头。
但绝不使用相对路径。
答案 1 :(得分：4)
第一个选项显示为较少约束。
如果明天项目目录的结构发生变化，您是想修改一个makefile还是更改每个自定义#include以考虑更改？
使用第二个选项会使对目录结构的更改花费更多时间，并且调整所有内容所需的时间将随项目大小而变化（而makefile更改时，它是常量）。
答案 2 :(得分：2)
这是一个主观的答案;如果两者都工作，那么两者都是正确的，但我更喜欢不知道源代码中的源代码树，只有在项目设置/ Makefile中，所以对我来说第一个选项是最好的：
#include "mycode.h"
答案 3 :(得分：2)
正如trojanfoe所说，这是非常主观的，但我仍然会采用以下这种风格。
#include "mycode.h"
如果需要重新构建具有.cpp / .h文件的文件夹，则以下样式将变得脆弱并且必然会失败。您将被迫更改.cpp文件以提供正确的相对路径。
#include "../../project_name/inc/mycode.h" //
答案 4 :(得分：0)
似乎包含#include（即option2）中的代码结构会降低代码的可移植性。
我最近遇到的问题是将一个组件（用卡纸构建）带到cocoapod以供IOS使用。主要问题是在代码中有以下代码
`#include <impl/xxxxx.h>`
当进入cocoapods时，它不会被编译，因为＆＃34; impl＆＃34;没有被识别，我没有找到一个设置。（我错了，只是分享我现在得到的）。改为
`#include "impl/xxxx.h" `
会使这个pod编译成succ，但仍然不能用作客户端。 sicne客户端代码不知道＆＃34; impl＆＃34;结构。（如果公共接口没有这个结构包含，它将起作用。但它不是我的情况）
我最终删除所有这些源结构包括哪个使用选项1 ..
所以我的意思是。 1）对于公共头，避免包含源结构。 2）对于私有标题/代码，使用＆＃34; private / source / structure / xxxx.h＆＃34;轻松编译设置。
请与我分享。