我应该避免使用typedef,尝试使用原始名称并在可能的情况下进行转换吗？

Question

我不确定这里的词汇,但希望我能让自己明白.

当我正在使用一个不那么坚如磐石的C++知识来完成winapi时,我发现很多typedef的东西,对我来说,似乎使问题过于复杂,并添加了一件我必须记住的事情.

例如,UINT而不是unsigned int,HBITMAP结果只是一个HANDLE,而很多其他.

我的问题是,是否可以/应该在可能的情况下替换该类型的更通用版本,并在需要时将其删除(以及这称为什么)？

例如,我想写

• void SomeFunction(unsigned int some_int) { ... } 代替 void SomeFunction(UINT some_int) { ... }

• HANDLE hBMP = LoadImage(...); ImageList_Add(... (HBITMAP) hBMP ...); 代替 HBITMAP hBMP = ...

这对新手来说是好事,一般来说是不好的做法,还是什么？

Answer 1

1)Win32 API实际上是C,而不是C++.

如果你考虑像MFC或ATL这样的东西,这两者都是"面向对象的",只有C++的API,这一区别变得更加重要.而这两个都是仁慈地变得(已成为？)过时了.

2)Microsoft喜欢使用大量的宏和typedef.我不能说这是"好"还是"坏".这只是生活中的一个事实.如果您在Windows上工作任何时间长度,它将成为您的第二天性.

3)最重要的是 - 是的:当您使用Microsoft API时,您应该遵循Microsoft惯例.当MSDN页面显示"HANDLE"时使用"HANDLE"是一件好事.类似的建议适用于"LPxxx","TRUE","FALSE","INVALID_HANDLE","HRESULT"等等.如果这就是它在MSDN中所说的那么,那就是你应该使用的.

它不仅会使您的代码更具可读性......但是,令人惊讶的是,它还可以防止 "第二次猜测""真实类型"可能导致的细微错误.

千万不能尝试"第二次猜测"的类型.这只是一个坏主意.

遵循标准惯例将使生活更轻松,更安全,更可靠,更便携.

恕我直言...

Answer 2

请不要typedef明显的(即UINT供unsigned int).相反,typedef传达意义.UINT没有优于unsigned int(有些人可能会认为它是短,但严重的是,这并不是说要短得多).

一个typedef相当长的名字(如typedef为std::map<unsigned int, flost>::const_iterator),在我看来,没关系,因为它提高了可读性.UINT... 没那么多.

A typedef传达特定类型/用途(如HANDLE)的具体含义是体面的.HANDLE在我看来,比使用原料更好,void*因为a)我不在乎是否HANDLEa void*,b)它传达了它的目的.

甲typedef用于便携性好的(例如对于32位带符号整数一个typedef),因为它允许平台/编译器之间更容易转变.