logo标签列表

使用""或<>包含boost头文件

c++compiler-constructioncoding-stylec-preprocessorconventions
3

为什么元组文档建议使用以下语法：

#include "boost/tuple/tuple.hpp"

而非

#include <boost/tuple/tuple.hpp>

我知道我的代码中不太可能会有一个名为"boost/tuple/tuple.hpp"的文件，但是使用#include <>明确表示不要在当前目录中查找。

那么原因是什么呢？

我认为这个提交需要有人来编辑拼写。 - chollida
我怀疑他们不在意，我想知道为什么 ;) 这正是问题的目的。 - dimba
6个回答
7

使用<>并不意味着“不要查找当前目录” - 它的意思是在一个实现定义的位置查找，然后再查找其他地方，也是实现定义的。这两个位置中的任何一个或两个都可能是当前目录。这是C++标准中比较无用的一部分。

这是C++标准中更无用的部分之一。还有C语言。我遇到一个实际案例，其中src/a.c包含了inc/component/b.h文件，而b.h文件又包含了"c.h"。一个编译器在src/目录下查找（然后继续查找其他路径），而另一个编译器在inc/component/目录下查找（然后继续查找其他路径）。花了一些时间来解决那个项目的make/build文件。我们统一将inc/放在包含路径中，a.c文件包含"component/b.h"，而b.h文件包含"component/c.h"。但即使如此，这仍然不是真正可移植的，因为"/"符号的含义没有定义。 - Steve Jessop
2
我怀疑绝大多数C和C++程序员对于#include在他们具体的实现中到底起到什么作用毫不知情 - 我知道我是不知道的。 - anon
3
我知道它的作用。在我的机器上可以运行。 - Steve Jessop
5
< p > <somefile> 的历史含义是查找系统标准位置。 对于 "somefile" ，它表示查找当前目录以及其他一些位置。

上次我发表那个答案时得到了-3分，尽管它（几乎）是正确的 :-*。使用引号“ ”和其他库< >来包含你的文件看起来更整洁。我试过的所有编译器都产生了你所描述的效果，即使标准说的不一样。但我怀疑是否值得为此而开战。 - Chris Huang-Leaver
4
据我所知，这样做是为了区分属于应用程序的标头和来自外部库的标头。我不能说为什么他们没有使用这个约定。这只是一种约定，而不是规则。
也许有人应该与Boost维护者提出这个问题？
4

使用 <...> 来引用 boost 库。这不是你的代码。除非你的代码本身就是 boost 库。

使用 "...." 来引用头文件，这在每个 C++ 程序中都必须有。这是为了读者方便，而不是为了编译器。

2
+1 对于我赞同的回答。哎呀！这开始让“人为气候变化”看起来像一个简单、易于达成一致的琐事了 :-( - Chris Huang-Leaver
@ChrisHuang-Leaver：我真的很想得到那个 - 但是我不 *嗯 - Florian
0

来自msdn：

引用形式

这种形式指示预处理器在包含#include语句的文件所在目录中查找包含文件，然后在包含（#include）该文件的任何文件的目录中查找。然后，预处理器沿着由/I编译器选项指定的路径搜索，然后沿着INCLUDE环境变量指定的路径搜索。

尖括号形式

这种形式指示预处理器首先沿着由/I编译器选项指定的路径搜索包含文件，然后，在从命令行编译时，沿着由INCLUDE环境变量指定的路径搜索。

MSDN不是C++标准，它没有提及INCLUDE变量，甚至没有提及目录。 - anon
1
@Neil：但是在你的回答中，你指定了它在一个实现定义的位置查找。所以对于编译器来说，这是由msdn（可能是VS）记录的。这就是规范中提到的具体实现细节的说明。 - Martin York
确实如此。我的意思是，MSDN 描述的行为并不适用于所有 C++ 实现。 - anon
0
你是在问两种包含风格的区别，还是在问Boost的理由？既然其他人已经谈到了区别，我只想对后者问题发表一下我的看法：
一般来说，我认为没有哪一种更正确。这取决于你的项目在依赖方面的结构。例如，在我的项目中，我通常将相关的Boost等内容包含在项目的子目录中，因此更倾向于使用#include ""形式。如果你想从一个更全局的位置获取Boost安装，你会更喜欢#include <>形式。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接