c++ header 本身不包含依赖 header

Question

tlhelp32.h 不包含 windows.h 本身是有原因的吗？我一直在与大量的编译器错误作斗争，因为我在包含 tlhelp32.h 之后包含了 windows.h。这是设计决定还是出于什么原因？我是 C++ 的新手，所以我不明白。如果 header 具有依赖项，则应包含它们。

#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;
}

Answer 1

大多数其他 Windows header 没有 #include <windows.h> ，但想当然地认为你已经这样做了。

据我所知，“原因”是他们基本上假设除 Windows.h(及其包含的标题)之外的每个文件的第一行是 #include <windows.h> , 所以检查它会浪费时间。

这基本上归结为两种不同风格的碰撞。我称之为“传统”C View 的是每个 header 只是 定义了自己的实体。如果它使用来自其他文件的实体，编写源代码的人应该知道所有的标题，以及它们需要包含的顺序。这让图书馆作者的生活变得简单，但代价是(经常)让他们制作的图书馆更难让用户实际使用。

当 C 委员会开始标准化 C 时，他们或多或少地拒绝了这种方法，而是选择了一种方法，其中每个 header 从用户的角度来看都是独立的，并且(在几乎所有情况下)包含一个 header 是幂等的(即，直接或间接地重复包含相同的 header 不会导致问题)。这通常会使使用图书馆的人的生活变得更简单，但代价是让图书馆作者的生活变得更加困难。

Windows.h 本身有点倾向于后者，但许多依赖于它的其他 header 更倾向于前者(至少在 windows.h 的特定情况下)。