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