诸如“../include/header.h"之类的相对路径有什么好处?标题? [英] What are the benefits of a relative path such as "../include/header.h" for a header?

问题描述

我已经查看了问题如何正确使用包含指令和C++ #include 语义 并没有解决这个问题 - 当我输入标题时，SO 建议的其他人也没有..

I've reviewed questions How to use include directive correctly and C++ #include semantics and neither addresses this - nor do the others suggested by SO when I typed the title...

写作有什么好处(如果有的话):

What, if any, are the benefits of writing:

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

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

compared with using just a plain file name:

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

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

or perhaps a relative name without the '..':

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

我看到的问题是:

• 您无法移动标题而不担心哪些源文件包含它.
• 您最终可能会在依赖项和错误报告中获得非常长的标题路径.我今天有一个../dir1/include/../../include/../dir2/../include/header.h".

我能看到的唯一优点是，虽然您不需要移动文件，但您可能无需总是使用 '-I' 指令来查找标题，但会丢失灵活性，以及​​在子子目录中编译的复杂性等似乎超过了好处.

The only merit I can see is that while you do not need to move files around, you might be able to get away without always using '-I' directives to find headers, but the loss of flexibility, and the complexity of compiling in sub-sub-directories, etc seems to outweigh the benefit.

那么，我是否忽略了一个好处?

So, am I overlooking a benefit?

感谢您的意见.我认为共识是使用我忽略的.."表示法没有任何重大好处.一般来说，我喜欢somewhere/header.h"表示法；我确实在新项目中使用它.我正在研究的不是新的.

Thanks for the inputs. I think the consensus is that there aren't any major benefits to the notation using ".." that I'm overlooking. In general terms, I like the "somewhere/header.h" notation; I do use it in new projects. The one I'm working on is anything but new.

其中一个问题是有各种不同的标头集，通常带有前缀，例如 rspqr.h、rsabc.h、rsdef.h、rsxyz.h.这些都与 rsmp 目录中的代码有关，但一些头文件在 rsmp 中，而另一些则在中心包含目录中，其中没有子目录作为 rsmp 在里面.(并对代码的其他各个区域重复此操作；在多个位置有标头，其他代码位随机需要.)移动内容是一个主要问题，因为多年来代码变得如此复杂.并且提供的 -I 选项的生成文件不一致.总而言之，这是一个几十年来不那么善意的忽视的悲惨故事.在不破坏任何东西的情况下修复这一切将是一项漫长而乏味的工作.

One of the problems is that there are various sets of headers, often with a prefix such as rspqr.h, rsabc.h, rsdef.h, rsxyz.h. These are all related to code in the rsmp directory, but some of the headers are in rsmp and others are in the central include directory, which does not have sub-directories such as rsmp in it. (And repeat for the various other areas of the code; there are headers in multiple locations, needed randomly by other bits of code.) Moving stuff around is a major problem because the code has gotten so convoluted over the years. And the makefiles are not consistent in which -I options are provided. All in all, it is a sad story of not-so-benign neglect over a period of decades. Fixing it all without breaking anything is going to be a long, tedious job.

推荐答案

我更喜欢路径语法，因为它非常清楚头文件属于哪个命名空间或模块.

I prefer the path syntax as it makes it very clear what namespace or module the header file belongs to.

#include "Physics/Solver.h"

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

Is very self-describing without requiring every module to prefix their name to header files.

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

I almost never use the ".." syntax though, instead I have my project includes specify the correct base locations.

这篇关于诸如“../include/header.h"之类的相对路径有什么好处?标题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！