C/C++ #include格式化最佳实践

Question

在我使用C/C++时,在.cpp/.c文件中包含.h文件时,我遇到了处理#include指令文件路径的不同方法.Google样式指南暗示在#include中使用部分文件路径.话虽这么说,我目前正在开发一个项目(尽管是一个小项目),当我"继承"代码时,我为我准备了一个精心布局的Makefile(用于G ++)和结构.也就是说,有一个名为/ project_name的目录,里面是Makefile和几个子目录.例如,/ project_name/inc包含.h文件,/ project_name/src包含.cpp文件.Makefile设置为查看每个子目录以编译源代码.

我的问题是,给定目录结构和Makefile,#include的"首选"方法是什么.我成功使用的两个备选方案如下所示.

1. 包括"mycode.h"//没有路径知识,假设我描述的结构

2. 包括"../../project_name/inc/mycode.h"//似乎有点复杂,但显示文件结构更好

我还缺少其他选择吗？

Answer 1

两者都不用.而是将所有公共标题放在具有单个根的某个层次结构中.例如,如果您的项目是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是更容易看到什么是公共和私有标头.

但绝不要使用相对路径.

Answer 2

第一个选项显示为较少约束。

如果明天项目目录的结构发生变化，您是愿意修改一个 makefile 还是更改每个自定义#include以将更改考虑在内？

使用第二个选项将使目录结构的更改花费更多时间，并且适应所有内容所需的时间将随着项目大小而变化（而随着 makefile 的更改，它是恒定的）。