Question

为什么tlhelp32.h不包含windows.h本身？我正在与大量的编译器错误作斗争，因为我在包括tlhelp32.h之后包含了windows.h。这是一个设计决定还是出于什么原因？我是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;
}

Answer 1

其他大多数Windows标题都不是#include <windows.h>，但理所当然地认为您已经这样做了。

据我所知，＆＃34;为什么＆＃34;是因为他们基本上假设除了Windows.h之外的每个文件的第一行（以及它包含的标题）是#include <windows.h>，所以检查它将是浪费时间。

这基本上归结为两种不同风格的碰撞。我称之为＆＃34;传统＆＃34; C视图是每个标题只是定义了自己的实体。如果它使用来自其他文件的实体，那么编写源代码的人应该知道所有头文件以及它们需要包含的顺序。这使得作者的生活变得简单，代价是（经常）使他们制作的库更难以供用户实际使用。

当C委员会开始标准化C时，他们或多或少地拒绝了这种方法，而选择了一种方法，其中每个标题看起来独立于用户的观点，并且（几乎在所有情况下）包含标题是幂等的（即，重复包括相同的标题，直接或间接，没有引起问题）。这通常会使使用图书馆的人的生活更加简单，但却会使图书馆作者的生活变得更加困难。

Windows.h本身倾向于后者，但依赖于它的许多其他标题更倾向于前者（至少在windows.h的特定情况下）。

c ++标头本身不包含依赖标头

1 个答案: