我正在玩 gmock 并注意到它包含这一行：
#include <tuple>
我会预料到tuple.h的。
什么时候可以排除扩展名，它是否赋予指令不同的含义？
Gordon Wilson
问问题
13901 次
7 回答
67
C++ 标准头文件没有“.h”后缀。我相信原因是该标准会破坏许多不同的标准前实现。因此，标准委员会没有要求供应商将其现有的“iostream.h”（例如）标头更改为符合标准（这将破坏其现有用户的代码），而是决定他们将删除后缀（我相信不会那么现有的实施已经完成）。
这样，现有的非标准程序将继续使用供应商的非标准库工作。当用户想要使他们的程序符合标准时，他们将采取的步骤之一是更改“ #include”指令以删除“.h”后缀。
所以
#include <iostream> // include the standard library version
#include <iostream.h> // include a vendor specific version (which by
// now might well be the same)
正如其他答案所提到的，非标准库的编写者可以选择任一命名约定，但我认为他们希望继续使用“.h”或“.hpp”（正如 Boost 所做的那样），原因有几个：
- 如果 & 当库标准化时，标准版本不会自动覆盖以前的非标准版本（很可能会导致用户代码损坏）
- 似乎（或多或少）没有后缀的标头是标准库，而带有后缀的标头（旧的 C 标头除外）是非标准的。
请注意，当委员会将哈希映射添加到 STL 时，发生了类似的问题——他们发现已经存在许多（不同的）hash_map实现，所以今天没有提出一个标准的实现，它破坏了很多东西，他们称标准实现为“ unordered_map”。命名空间应该有助于防止这种类型的跳跃，但它似乎不够好（或使用得不够好）以允许他们在不破坏大量代码的情况下使用更自然的名称。
请注意，对于“C”标头，C++ 允许您包含 a<cxxxxxx>或<xxxxxx.h>变体。以“c”开头且没有“.h”后缀的将其声明放入std命名空间（可能还有全局命名空间），带有“.h”后缀的将名称放入全局命名空间（一些编译器也将名称放在名称std空间中-我不清楚这是否符合标准，尽管我没有看到危害）。
于 2009-01-14T02:14:02.203 回答
20
如果文件被命名tuple，那么你需要#include <tuple>
如果它被命名tuple.h，那么你需要#include <tuple.h>
就这么简单。您没有省略任何扩展名。
于 2009-01-14T01:25:44.063 回答
15
它包括一个简单命名为“元组”的文件——文件本身没有扩展名。
C++ 包含文件的假定标准是命名它们时不带 .h 扩展名；许多库编写者遵循这个标准（STL 等），但有些不遵循。
于 2009-01-14T01:27:34.010 回答
8
没有什么特别的事情发生。该文件被简单命名为tuple.
原因...标准库头文件没有文件扩展名是因为namespaces.
命名空间是在游戏后期与 C++98 标准一起添加到 C++ 标准的，包括std所有标准库实体所在的命名空间。
当标准库移到std命名空间时，这意味着所有现有的 C++ 代码都会中断，因为所有代码都希望该库位于全局命名空间中。解决方案是不理会旧的“dot-h”头文件，并在没有扩展名的文件中提供命名空间库。
这样，旧代码#include<iosteam.h>可以期待一个全局的cout，而新代码可以#include<iostream>并且期待一个std::cout.
于 2009-01-14T02:57:14.113 回答
5
除了已经发布的很好的答案之外，应该注意的是，C++ 标准不需要指令“#include <iostream>”来读取名为“iostream”甚至“iostream.h”的文件。它可以被命名为“fuzzball”。或者，可能不存在相应的文件，并且定义被构建到编译器中并由 include 指令激活。
于 2009-01-14T02:59:31.673 回答
4
我的理解是#include 元组将“指向” tuple.h。
于 2009-01-14T01:35:07.647 回答
-3
伙计们，
我认为交易是：#include <lib> 总是将 /lib/include 附加到搜索路径（.h 是infrerred），而 #include <lib.h> 只搜索 -I<pathname>。
请注意，我可能是错的......这就是我认为它的工作方式（在 Solaris 上的 Forte cc 中）。
于 2009-05-23T10:10:15.357 回答