什麼時候可以在#include指令中省略文件擴展名？

Question

我玩弄gmock，發現它有這樣一行：

#include <tuple> 

我本來期望tuple.h。

什麼時候可以排除擴展名，它是否賦予該指令不同的含義？

Answer 1

的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」 （如升壓已經做）的一對夫婦的原因：

1. 如果&當庫被標準化，標準版將不會自動覆蓋前面的，不規範的一個（在所有可能導致用戶斷碼）
2. 它似乎是一個約定（或多或少），沒有後綴的標題是標準庫，而具有後綴（而不是舊的C標頭）的標準是非標準的。

注意，類似的問題發生時，委員會成員們來到哈希映射添加到STL - 他們發現，目前已經有很多（不同的）hash_map實現存在的，所以不是想出打破一個標準今天有很多東西，他們正在調用標準實現「unordered_map」。命名空間應該有助於防止這種類型的跳躍，但它似乎沒有足夠好（或足夠好的使用），以允許它們使用更自然的名稱而不會破壞很多代碼。

請注意，對於'C'頭文件，C++允許您包含<cxxxxxx>或<xxxxxx.h>變體。以'c'開頭並且沒有「.h」後綴的名稱將其聲明放在std名稱空間（可能還有全局名稱空間）中，後綴名爲「.h」的名稱將全局名稱空間（某些編譯器也是把名字放在std命名空間中 - 我不清楚這是否符合標準，儘管我沒有看到這種傷害）。

Answer 2

如果文件被命名爲tuple，那麼你需要#include <tuple> 如果它的命名tuple.h那麼你需要#include <tuple.h>

就這麼簡單。你沒有忽略任何擴展。

Answer 3

它包含一個簡單名爲「tuple」的文件 - 文件本身缺少擴展名。

C++包含文件的推定標準是爲它們命名，不帶.h擴展名;許多圖書館作家都遵循這個標準（STL等），但有些則沒有。

Answer 4

我的理解是#include元組將「指向」tuple.h。

檢查了這一點：iostream vs iostream.h

Answer 5

沒有什麼特別的。該文件簡稱爲tuple。

原因是這個......標準庫頭沒有文件擴展是因爲namespace s。

命名空間被添加到C++標準下旬在與C++ 98標準的遊戲，包括std命名空間，所有的標準庫實體方式支付。

當標準庫得到了移動到std命名空間，這意味着所有現有的C++代碼都會中斷，因爲它所有的代碼都希望該庫位於全局名稱空間中。解決方案是單獨保留舊的「dot-h」頭文件，並在沒有擴展名的文件中提供名稱空間庫。

這樣，舊代碼#include<iosteam.h>可能會預計全球cout，而新代碼可能#include<iostream>和預計std::cout。

Answer 6

除了已發佈的良好答案之外，應該注意的是，C++標準不需要指令「#include <iostream>」來讀取名爲「iostream」的文件，甚至不需要「iostream.h」。它可以被命名爲「絨球」。或者，可能不存在相應的文件，並將定義內置到編譯器中並由include指令激活。

Answer 7

夥計們，

我認爲這筆交易的：#include <LIB>八方通預會掛起/ lib中/包含到搜索路徑（.H是infrerred），而的#include <lib.h>搜索只是-I <路徑名稱>。

請注意，我可能是錯的...這只是我認爲它的工作原理（在Solaris上的Forte cc）。