为什么WAIT_OBJECT_0定义为((STATUS_WAIT_0)+ 0)

zoz*_*nia 5 c++ windows winapi

winbase.h标题中,您可以找到以下行:

#define WAIT_OBJECT_0       ((STATUS_WAIT_0 ) + 0 )
Run Code Online (Sandbox Code Playgroud)

STATUS_WAIT_0winnt.h标题中定义如下:

#define STATUS_WAIT_0       ((DWORD)0x00000000L)
Run Code Online (Sandbox Code Playgroud)

并且DWORD是typedef'd unsigned long.

我的问题是,为什么0增加STATUS_WAIT_0价值?

Jam*_*nze 9

有两个可能的原因.首先是可读性.如果有一系列的#defines:

#define WAIT_OBJECT_0 ((STATUS_WAIT_0) + 0)
#define WAIT_OBJECT_1 ((STATUS_WAIT_0) + 1)
//  ...
Run Code Online (Sandbox Code Playgroud)

在这种情况下,指出((STATUS_WAIT_0) + 0) 正交性的原因是有意义的:您正在定义一系列基于的值STATUS_WAIT_0,而这恰好是偶然的0,而不是其他一些值.

第二个可能的原因涉及整体推广.作者希望WAIT_OBJECT_0拥有推广类型 STATUS_WAIT_0,无论其类型如何STATUS_WAIT_0.增加确保整体推广.


ica*_*bod 5

其他答案没有解决的STATUS_WAIT_0一个重点是NTSTATUS(NTSTATUS值)的可能值之一. NTSTATUS主要用于编写设备驱动程序时.

当您执行WaitFor...的事情,这是可能的执行将下拉到内核,并根据你从设备驱动程序还等什么,结果将是一个NTSTATUS类型(1)

因此,在用户模式下等待的结果基于Wait in kernel模式的结果是有道理的,因此:

#define WAIT_OBJECT_0 ((STATUS_WAIT_0 ) + 0 )
Run Code Online (Sandbox Code Playgroud)

现在,至于为什么我们添加零......正如詹姆斯坎泽所说,它使得事物在WAIT_OBJECT_1定义的情况下更具可读性.一致性是可维护性的重要组成部分.

至于为什么STATUS_WAIT_0要转换为DWORD...这是因为0x0L作为常量的值将根据编译器而变化,因此强制转换可确保您确切知道该类型的大小.


(1)不是设备驱动程序的作者,我不能假设这个陈述在100%的时间都是真的,但它有道理:)