什么时候可以在#include指令中省略文件扩展名？

我正在玩gmock并注意到它包含这一行:

#include 

我原以为是tuple.h.

什么时候可以排除扩展名,它是否赋予指令不同的含义？

1> Michael Burr..：

---

C++标准头文件后缀没有".h".我相信原因是标准会破坏许多不同的预标准实现.因此,标准委员会决定他们放弃后缀(我相信没有),而不是要求供应商将其现有的"iostream.h"(例如)标题更改为符合标准(这将破坏其现有用户的代码).然后现有的实施已经完成).

这样,现有的非标准程序将继续使用供应商的非标准库.当用户想要使他们的程序标准兼容时,他们将采取的步骤之一是更改" #include"指令以删除".h"后缀.

所以

#include      // include the standard library version
#include    // 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 或变体.以'c'开头并且没有".h"后缀的那个将它们的声明放在std命名空间(可能还有全局命名空间)中,带有".h"后缀的那些将名称放在全局命名空间中(一些编译器也放了std命名空间中的名称 - 我不清楚这是否符合标准,但我没有看到它的危害.

---

另一个(可能不是主要原因:))可能指向标准标题根本不需要是文件.所以他们可以决定放弃".h",因为它建议文件扩展名.

---

这是自ANSI C 1989以来的真实情况,它有一个脚注:"标题不一定是源文件......"顺便说一句 - 是否有人知道编译器除了标准标题的普通源文件之外还做了什么？

---

@MichaelBurr预编译的头文件是否适合该帐单？

2> Ferruccio..：

---

如果该文件已命名,tuple那么您需要,#include 如果它已命名,tuple.h那么您需要#include

就这么简单.您没有省略任何扩展名.

3> Crashworks..：

---

它包含一个简单命名为"元组"的文件 - 文件本身缺少扩展名.

C++包含文件的推定标准是在没有.h扩展名的情况下命名它们; 许多图书馆作家都遵循这个标准(STL等),但有些则没有.

4> Drew Dormann..：

---

没有什么特别的事.该文件只是命名tuple.

这个原因...标准库头没有文件扩展是因为namespaces.

命名空间在游戏后期使用C++ 98标准添加到C++标准中,包括std所有标准库实体所在的命名空间.

当标准库移动到std命名空间时,这意味着所有现有的C++代码都会破坏,因为它们都希望库位于全局命名空间中.解决方案是单独保留旧的"dot-h"头文件,并在没有扩展名的文件中提供命名空间库.

这样,旧代码#include可以期待全局,cout而新代码可以#include并且期望a std::cout.