我目前正在处理一个 Windows 应用程序项目。 我正在使用 Windows API 开发它，我需要设置一些标准。
重要的：
谢谢。
编辑： 您如何看待 SAL 注释？ http://msdn.microsoft.com/en-us/library/hh916382.aspx
我应该在头文件中使用它吗？
【问题讨论】：
long 对于不同的编译器和平台可以是 4 字节或 8 字节。 DWORD 在 IntSafe.h 中声明，因此必须比其他安全:)
这个问题的一部分只是意见，但我的建议是：
我会同意 DWORD 这样的事情。您不应该为 Windows 数据类型假定特定的基础类型。你应该只假设如果函数说它需要一个DWORD，那么你需要为它提供一个DWORD。它确保如果 Microsoft 更改了基础类型，那么您的代码应该仍然可以正常工作，而无需进行任何更改。
WPARAM 和 LPARAM 类型就是一个很好的例子，我认为它们已经更改了几次。现在它们基本上被定义为“大到足以容纳一个指针”，这意味着它们在 32 位和 64 位 Windows 之间是不同的大小。
我会拒绝 LPCTSTR 之类的东西，因为对我来说，说 const TCHAR* 更清楚——整个“长指针”是 16 位 Windows 的遗物。但是请注意，我说的是const TCHAR*，而不是const wchar_t*。
谈到在任何地方使用它时，我会说绝对不要在需要可移植的代码的任何部分中使用它 - 尽管您可以在编译时创建自己的 typedef，其基础类型是 Windows 数据类型对于 Windows，例如：
typedef TickCount DWORD;
如果您尝试使用可能具有“滴答计数”概念并需要在另一个操作系统上运行的代码，我会很烦恼，但此时您需要在代码和 Windows API 之间建立一个抽象层，无论如何。
已编辑问题的更新：
我自己对 SAL 没有任何经验，但乍一看这似乎不是一个糟糕的主意。它明确了如何在不依赖文档的情况下使用参数，并且正如 MSDN 文档所说，他们将其与静态代码分析工具一起使用。如果您有这样的工具可以确认您正在正确使用注释，那么这对我来说似乎是件好事。我的直接反应是它确实使声明更难阅读，但定义 API 的最困难的事情之一是确保预期的行为得到充分记录和理解。
【讨论】：
对于直接转到 Windows API 的值，请使用 windows 类型。对于仅用于您自己的内部计算的值，请使用您自己的类型（或类似 stdint.h 的东西）。对于两者都使用的值，请使用您自己的类型并在需要时转换为 windows 类型。
【讨论】：