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

Question

Is there a reason why tlhelp32.h does not include windows.h itself ? I was fighting with tons of compiler errors because I included windows.h after including tlhelp32.h. Is it a design decision or for what reason ? I am new to c++ so i dont get it. If a header has dependencies it should include them.

#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

Most of the other Windows headers don't #include <windows.h> , but take for granted that you've done so.

As far as I can tell, the "why" is that they basically assume the first line of every file other than Windows.h (and the headers it includes) is #include <windows.h> , so checking for it would be a waste of time.

This basically comes down to a collision of two different styles. What I'd call the "traditional" C view was that each header just defined its own entities. If it used entities from other files, the person writing the source was expected to know all the headers, and the order in which they needed to be included. This kept life simple for library authors , at the expense of (frequently) making the libraries they produced more difficult for users to actually use.

When the C committee started to standardize C, they more or less rejected this approach, opting instead for an approach where each header looked independent from a user's point of view, and (in nearly all cases) inclusion of a header was idempotent (ie, repeatedly including the same header, directly or indirectly, didn't cause a problem). This generally makes life simpler for the person using a library, at the expense of making the library author's life a little more difficult.

Windows.h itself sort of leans toward the latter, but many of the other headers that depend on it lean more toward the former (at least in the specific case of windows.h).