我应该为我的项目使用相对包含路径，还是将包含目录放在包含路径上？
在我的项目中，我目前使用相对路径来包含我的文件，这无疑不会经常改变。然而，它会产生非常奇怪的包含模式，因为我通常将文件嵌套在很多文件夹中。
例如，在我当前的项目中，我有 network/server/myfile.hpp。它需要包含 common/log.hpp。目前我使用 #include "../../common/log.hpp" 这是相当冗长的，但有效。
如果我在路径上添加主包含目录，我可以简单地包含 "common/log.hpp"。
我知道这个问题可能更多地与偏好有关，但是关于跨平台应用程序以及 C++ 约定是否有任何客观的利弊？
In my project, I currently use relative paths to include my files, which admittedly doesn't change often. However, it yields pretty weird include patterns, because I usually nest my files in alot of folders.
For example, in my current project I have network/server/myfile.hpp. It needs to include common/log.hpp. Current I use #include "../../common/log.hpp" which is pretty verbose, but works.
If i instead add my main include directory on the path, I could simply include "common/log.hpp".
I know this question might be more about preference than anything else, but is there any objective pros and cons concerning cross platform applications and what about C++ conventions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
相对包含带有
..的路径看起来有点难看，并且需要特定的文件系统结构，即"../../common/log.hpp"是两个文件夹。一般而言，尤其是文件系统结构上避免不必要的依赖关系是有意义的，因此将头文件从一个目录移动到另一个目录不会强制您更新包含该头文件的所有源文件。让您的包含对应于名称空间和类也是很优雅的。例如，如果您有：
将其包含起来既方便又直观，如下所示：
Relative includes paths with
..in it look a bit ugly and expect a certain filesystem structure, that is,"../../common/log.hpp"is two folders up. It makes sense to avoid unnecessary dependencies in general and on filesystem structure in particular, so that moving a header file from one directory to another does not force you to update all source files that include that header.It is also elegant to have your includes correspond to namespaces and classes. If, for example, you have:
It is convenient and intuitive to include it like:
通过在源文件中包含
#include并在项目设置（编译器选项）中包含common/log.hpp的路径，您可以保护如果common/log.hpp移动到其他地方，您的源代码就会发生变化，所以我推荐这种方法。请注意，在这种情况下使用尖括号 - 编译器应在/I编译器选项指定路径的目录中搜索标头。By having
#include <common/log.hpp>in your source file and having path tocommon/log.hppin your project settings (compiler options) you are protecting your source code from changes in casecommon/log.hppmoves to some other place so I would recommend this approach. Note using angle brackets in this case - compiler should search for the header in directories which paths are specified by the/Icompiler option.我总是努力让我的项目不受地点的影响。如果我在新的计算机/平台上工作，我希望能够使用最少的所需设置进行编译并继续工作。当您问一个主观问题时，我的主观答案是我绝对更喜欢使用相对路径。
I always strive to make my projects independent of location. If I work on a new computer/platform, I want to be able to compile and keep working with a minimum of required setup. As you're asking a subjective question, my subjective answer would be that I definitely prefer using relative paths.
没有这样的约定，您可以按照自己喜欢的方式进行。
此外，相对路径为您提供了移植应用程序的自由，所以就这样做吧:)
No CONVENTIONS as such, you may do it either way, the way you prefer.
And moreover relative paths provide you freedom to port you application, So just do it :)
我有一条规则，每个单独的组件不得使用多个目录，并且该组件在包含路径中具有依赖组件的目录。
因此，每个组件都使用自己的包含文件和
""语法，而其他组件的包含文件使用<>，这很好地避免了一个组件使用标头表明安装到系统包含目录中的最后一个部署版本而不是源树中的版本；它还具有迫使我尽早组件化我的项目的良好效果。I have a rule that each individual component may not use more than one directory, and that component have dependent components' directories in the include path.
Thus, each component uses its own include files with the
""syntax, and other components' includes using<>, which nicely avoids unpleasant surprises with one component using the header that the last deployed version installed into the system include directory rather than the one from the source tree; it also has the nice effect of forcing me to componentize my projects early on.