什么时候可以在#include指令中省略文件扩展名?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了什么时候可以在#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)
正如其他答案所提到的那样,非标准库的编写者可能会选择命名约定,但我认为他们会希望继续使用“.h”或“.hpp”(如Boost所做的那样),原因如下:
- 如果库得到标准化,标准版本将不会自动覆盖以前的非标准版本(导致用户代码损坏)
- 似乎是一种惯例(或多或少),没有后缀的标题是标准库,而带有后缀(旧C标题除外)的标题是非标准的。
请注意,当委员会向STL添加哈希映射时发生了类似的问题 - 他们发现已经存在许多(不同的)hash_map
实现,因此没有提出一个打破很多东西的标准实现今天,他们称之为标准实施“unordered_map
”。命名空间应该有助于防止这种类型的跳跃,但它似乎不能很好地工作(或使用得很好),以允许他们使用更自然的名称,而不会破坏大量的代码。
请注意,对于'C'标题,C ++允许您包含<cxxxxxx>
或<xxxxxx.h>
变体。以'c'开头并且没有“.h”后缀的那个将它们的声明放在std
命名空间(可能还有全局命名空间)中,带有“.h”后缀的那些将名称放在全局命名空间中(一些编译器)还把名字放在std
命名空间 - 我不清楚这是否符合标准,尽管我没有看到这种危害)。
如果该文件名为tuple
,那么你需要#include <tuple>
,如果它的名字是tuple.h
那么你需要#include <tuple.h>
就这么简单。您没有省略任何扩展名。
它包含一个简单命名为“元组”的文件 - 文件本身缺少扩展名。
C ++包含文件的推定标准是在没有.h扩展名的情况下命名它们;许多图书馆作家都遵循这个标准(STL等),但有些则没有。
没有什么特别的事。该文件名为tuple
。
这个原因......标准库头没有文件扩展名是因为namespace
s。
命名空间在游戏后期使用C ++ 98标准添加到C ++标准中,包括所有标准库实体所在的std
命名空间。
当标准库移动到std
命名空间时,这意味着所有现有的C ++代码都会破坏,因为它们都希望库位于全局命名空间中。解决方案是单独保留旧的“dot-h”头文件,并在没有扩展名的文件中提供命名空间库。
这样,旧代码将#include<iosteam.h>
可以期待全球cout
而新代码可以#include<iostream>
和期待std::cout
。
我的理解是#include元组会“指向”tuple.h。
除了已发布的精细答案之外,应该注意的是C ++标准不需要指令“#include <iostream>
”来读取名为“iostream”的文件,甚至“iostream.h”。它可以被命名为“fuzzball”。或者,不存在相应的文件,并且定义将内置到编译器中并由include伪指令激活。
伙计们,
我认为交易是:#include <lib>总是将/ lib / include添加到搜索路径(.h是红外线),而#include <lib.h>只搜索-I <pathname>。
请注意,我可能是错的...这就是我认为它的工作原理(在Solaris上的Forte cc中)。
以上是关于什么时候可以在#include指令中省略文件扩展名?的主要内容,如果未能解决你的问题,请参考以下文章
关于php中的include html文件的问题,为什么html可以在php中执行