什么时候可以在#include指令中省略文件扩展名？
我正在玩gmock，并注意到它包含这一行：
#include <tuple> 我会期待tuple.h 。
什么时候可以排除扩展名，是否赋予该指令不同的含义？
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)
正如其他答案所提到的，非标准库的作者可以select命名约定，但是我认为他们会想要继续使用“.h”或“.hpp”（如Boost所做的）
- 如果图书馆得到了标准化，标准版本不会自动覆盖以前的非标准版本（造成破坏的用户代码）
- 它似乎是一个约定（或多或less），没有后缀的标题是标准库，而具有后缀（不是旧的C标头）的标准是非标准的。
请注意，当委员会将散列映射添加到STL时，发生了类似的问题 – 他们发现已经有很多（不同的） hash_map实现存在，所以不是提出一个标准的散列映射今天，他们正在调用标准实现“ unordered_map ”。 命名空间应该有助于防止这种types的跳跃，但似乎没有足够的工作（或足够好的使用），使他们能够使用更自然的名字，而不会破坏大量的代码。
请注意，对于“C”头文件，C ++允许包含<cxxxxxx>或<xxxxxx.h>变体。 以'c'开始并且没有“.h”后缀的声明将它们的声明放在std命名空间（也可能是全局命名空间）中，后缀为“.h”的命名将全局名称空间（某些编译器也把名字放在std命名空间中 – 我不清楚这是否符合标准，尽pipe我没有看到伤害）。
如果文件被命名为tuple那么你需要#include <tuple>如果它被命名为tuple.h那么你需要#include <tuple.h>
就这么简单。 您不会忽略任何扩展。
它包含一个简单名为“元组”的文件 – 文件本身缺less扩展名。
C ++包含文件的推定标准是为它们命名，不带.h扩展名。 许多图书馆作家都遵循这个标准（STL等），但有些则没有。
没有什么特别的事情发生。 该文件是简单的命名tuple 。
这是因为标准库头没有文件扩展的原因是由于namespace 。
命名空间在C ++ 98标准的后期被添加到C ++标准中，包括所有标准库实体所在的std名称空间。
当标准库移动到std名称空间时，这意味着所有现有的C ++代码都会中断，因为它们都希望库位于全局名称空间中。 解决scheme是单独保留旧的“dot-h”头文件，并在没有扩展名的文件中提供名称空间库。
通过这种方式，包含#include<iosteam.h>旧代码可能需要一个全局的cout而新的代码可能包含#include<iostream>并期待一个std::cout 。
我的理解是#include元组将“指向”tuple.h。
检查一下： iostream vs iostream.h
除了已经发布的良好答案之外，应该注意的是，C ++标准不需要指令“#include <iostream> ”来读取名为“iostream”的文件，甚至不需要“iostream.h”。 它可以被命名为“fuzzball”。 或者，不存在相应的文件，并将定义内置到编译器中，并由include指令激活。
伙计们，
我认为这个交易是：#include <lib> allways pre pends / lib / include到searchpath（.h是infrerred），而#include <lib.h>只search-I <pathname>。
请注意，我可能是错的…这只是我认为它的工作原理（在Solaris上的Forte cc）。
