在源文件中指定包含前缀与在编译器的搜索路径参数中指定包含前缀有何优缺点?

use*_*733 3 c c++ compiler-construction

当 C 或 C++ 库附带多个标头时,它们通常位于特定文件夹中。例如,OpenCV在一个文件夹中提供了cv.h和。highgui.hopencv

包含它们的最常见方法是将此opencv文件夹添加到预编译器的搜索路径中(例如gcc -I/pathto/opencv),并简单地按源文件中的文件名包含标头(例如#include <cv.h>

还有一种替代方案,因为包含标头的文件夹与其他文件夹(例如,在开发团队的公共路径中或开发团队的某些公共路径中)经常位于/usr/include父文件夹中。#include <opencv/cv.h>在这种情况下,如果父文件夹已在路径中,则在源文件中指定头文件夹(例如 )就足够了。

我能想到的这种替代方案的唯一问题是所有标头都位于单个文件夹中的系统的情况。然而,这种替代方案可以防止歧义(例如,如果两个库都有一个vector.h标头),使得设置另一个构建系统变得更容易,并且对于预编译器搜索头文件来说可能更有效。

鉴于这种分析,我倾向于替代方案,但我在互联网上找到的绝大多数代码都使用第一种。例如,Google 返回大约 218000 个结果"#include <cv.h>",而返回 79100 个结果"#include <opencv/cv.h>"。我是否错过了普通方法的优点或替代方法的缺点?

Mat*_* M. 5

我个人的偏好是拥有<opencv/cv.h>

为什么 ?cv.h因为我是人类,大脑有限,还有比记住来自图书馆的东西更重要的事情要做opencv

因此,尽管我使用的库始终位于专用文件夹中,但我将它们构造为:

<specific library folder>/include/<library name>/...
Run Code Online (Sandbox Code Playgroud)

这有助于我记住这些标头的来源。

我知道有人说它没用,而且 IDE 无论如何都会直接带你到文件......但是

  • 我并不总是使用 IDE
  • 我并不总是想打开每个包含文件只是为了知道这个特定文件与哪些库相关

它还使得组织包含列表(以及相关的包含组在一起)变得更加容易。