C++頭文件本身不包含依賴文件頭

tlhelp32.h不包含windows.h本身的原因嗎？包含tlhelp32.h之後，我正在處理大量編譯器錯誤，因爲我包含了windows.h。這是一個設計決定還是出於什麼原因？我是新來的C++，所以我沒有得到它。如果一個頭文件有依賴關係，它應該包含它們。C++頭文件本身不包含依賴文件頭

#include <windows.h> 
#include <tlhelp32.h> 
#include <tchar.h> 

std::vector<unsigned long> GetProcessIdsHelper() 
{ 
std::vector<ULONG> result; 
auto snapshotHandle = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); 

if (snapshotHandle == INVALID_HANDLE_VALUE) 
    return result; 

PROCESSENTRY32 processEntry; 
if (!Process32First(snapshotHandle, &processEntry)) 
    return result; 

do 
    result.push_back(processEntry.th32ProcessID); 
while (Process32Next(snapshotHandle, &processEntry)); 

return result; 
}

來源

2017-06-21 Jason Grant

不回答爲什麼他們這樣做，但... https://stackoverflow.com/questions/34502661/c-tlhelp32-h-not-working – NathanOliver

它被認爲是一種很好的風格，在.cpp中你可以包括以任意順序選擇任何標題。微軟的某個人不知道或不關心或者有更重要的事情要做。特別是'windows.h'也會''定義'宏'比如'max'，然後搞亂標準庫。不要將這些頭文件作爲C++頭文件的例子。 – nwp

大多數其他Windows標頭不是#include <windows.h>，但認爲您已經這樣做是理所當然的。

據我所知，「爲什麼」是他們基本上認爲除了Windows.h以外的每個文件的第一行（和它包含的頭文件）是#include <windows.h>，因此檢查它會浪費時間。

這基本上歸結爲兩種不同風格的碰撞。我所說的「傳統」C視圖是每個標題只是定義了它自己的實體。如果它使用來自其他文件的實體，那麼編寫源代碼的人需要知道所有標題以及它們需要包含的順序。這對於圖書館作者來說保持了簡單的生命，代價是（經常）使它們生成的庫更難以供用戶實際使用。

當C委員會開始對C進行標準化時，他們或多或少地拒絕了這種方法，而是選擇了一種方法，其中每個標題看起來獨立於用戶的觀點，並且（在幾乎所有情況下）包含標題爲冪等（即直接或間接重複包含相同的標題不會導致問題）。這對於使用圖書館的人來說通常會使生活變得更簡單，但是會讓圖書館作者的生活變得更加困難。 Windows.h本身就傾向於後者，但依賴它的許多其他頭文件更傾向於前者（至少在windows.h的特定情況下）。

來源

2017-06-21 14:14:33

C++頭文件本身不包含依賴文件頭

回答

相關問題