对于标题,相对路径有什么好处,例如"../include/header.h"？

我已经回顾了问题如何正确使用include指令和C++ #include语义,并没有解决这个问题 - 当我输入标题时,SO也没有提出其他建议......

如果有的话,写作的好处是什么:

#include "../include/someheader.h"
#include "../otherdir/another.h"

与仅使用普通文件名相比:

#include "someheader.h"
#include "another.h"

或者没有' ..' 的相对名称:

#include "include/someheader.h"
#include "otherdir/another.h"

我看到的问题是:

您无法移动标题而不必担心哪些源文件包含它.

您最终可能会在依赖项和错误报告中使用非常长的标头路径.我今天有一个" ../dir1/include/../../include/../dir2/../include/header.h".

我能看到的唯一优点是,虽然你不需要移动文件,但是你可以在不使用' -I'指令来查找标题的情况下逃脱,但是失去灵活性,以及​​子子编译的复杂性 - 目录等似乎超过了好处.

那么,我是否忽视了一项福利？

---

感谢您的投入.我认为大家一致认为,使用"......"的符号没有任何重大好处,我忽略了.一般来说,我喜欢"somewhere/header.h"符号; 我确实在新项目中使用它.我正在努力的是新事物.

其中一个问题是,有各种套头的,往往带有前缀,如rspqr.h,rsabc.h,rsdef.h,rsxyz.h.这些都与rsmp目录中的代码有关,但有些标题位于其中rsmp,其他标题位于中央include目录中,该目录中没有子目录rsmp.(并重复代码的其他各个方面;在多个位置都有标题,需要其他位代码随机使用.)移动内容是一个主要问题,因为多年来代码变得如此复杂.并且makefile与-I提供哪些选项不一致.总而言之,这是一个悲伤的故事,讲述了几十年来不那么温和的疏忽.在不破坏任何东西的情况下解决所有问题将是一项漫长而乏味的工作.

1> Andrew Grant..：

---

我更喜欢路径语法,因为它非常清楚头文件所属的命名空间或模块.

#include "Physics/Solver.h"

非常自描述而不需要每个模块将其名称作为头文件的前缀.

我几乎从不使用".."语法,而是我的项目包括指定正确的基本位置.

2> bk1e..：

---

问题#include "../include/header.h"在于它经常会偶然发生,然后一个看似无关的变化会使它在以后停止工作.

例如,请考虑以下源布局:

./include/header.h
./lib/library.c
./lib/feature/feature.c

让我们说你正在使用包含路径运行编译器-I. -I./lib.怎么了？

./lib/library.c可以做#include "../include/header.h",这是有道理的.

./lib/feature/feature.c也可以这样做#include "../include/header.h",即使它没有意义.这是因为编译器将尝试#include相对于当前文件位置的指令,如果失败,它将尝试#include相对于路径中每个-I条目的指令#include.

此外,如果您稍后-I./lib从#include路径中删除,那么您就会中断./lib/feature/feature.c.

我发现以下内容更可取:

./projectname/include/header.h
./projectname/lib/library.c
./projectname/lib/feature/feature.c

我不会添加任何包括比其他路径项-I.,然后双方library.c并feature.c会使用#include "projectname/include/header.h".假设"projectname"可能是唯一的,这在大多数情况下不会导致名称冲突或模糊.VPATH如果绝对必要,您还可以使用包含路径和/或make的功能将项目的物理布局分割为多个目录(例如,为了适应特定于平台的自动生成的代码;这在您使用时确实会崩溃#include "../../somefile.h").

3> SingleNegati..：

---

IANALL,但我不认为你应该把它放在..实际的C或C++源文件中,因为那不是便携式的,标准不支持它.这类似于\在Windows上使用.只有在编译器无法使用任何其他方法时才能执行此操作.

---

零谷歌点击IANALL.我认为这是"我不是语言律师"？

---

好点子.该标准似乎甚至不能保证您可以使用正斜杠."该实现为由一个或多个非数字(lex.name)组成的序列提供了唯一的映射,后跟一个句点(.)和一个非数字." 它将nondigit定义为基本上[_a-zA-Z]或\ uNNNN.

---

的确是这样-但是有问题的软件已经在多种平台上编译了很多年（其中有二十多个），因此，它在理论上比实际上更具责任感。