我目前正在开发一个Windows应用程序项目。 我正在使用Windows API开发它,我需要设置一些标准。
重要的一个:
谢谢。
编辑: 您如何看待SAL注释? http://msdn.microsoft.com/en-us/library/hh916382.aspx
我应该在头文件上使用它吗?
答案 0 :(得分:2)
这个问题的一部分只是意见,但我的建议是:
我会对DWORD
之类的事情说“是”。您不应假设Windows数据类型的特定基础类型。您应该只假设如果函数说它需要DWORD
,那么您需要提供DWORD
。它确保如果Microsoft更改基础类型,那么您的代码应该仍然可以使用no进行最小的更改。
一个很好的例子是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的最棘手的事情之一就是确保预期的行为得到充分记录和理解。
答案 1 :(得分:1)
对于直接转到Windows API的值,请使用Windows类型。对于仅用于您自己的内部计算的值,请使用您自己的类型(或类似stdint.h)。对于两者中使用的值,请使用您自己的类型并在需要时强制转换为窗口类型。