api特定typedef的目的是什么,例如GLsizei GLint GLvoid？
我在c和c代码中到处都看到了这一点.基本类型通常使用库前缀/后缀来表示.这背后的原因是什么？这是好习惯吗？我的程序应该自己做类似的事吗？
乍一看似乎使代码的可读性稍差.您必须立即将GLint转换为int中的int,这是一个简单的例子.
像UINT之类的东西对我来说更多,至少这会将unsigned int缩短为四个字母.
解决方法
这不是关于缩短名称,而是关于可移植性.不同的平台需要以不同方式键入这些内容.
在Std-C中,long可能是32位或64位,具体取决于您的编译器/目标,因此不能安全地假设它是一定的大小.因此,图书馆作者将根据目标平台的知识键入自己的类型,保证一定的大小.
例如.
#ifdef _WIN32 typedef __int64 INT64; // long will not be 64 bit on Windows/VC. #elif __GNU_C__ typedef long INT64; // gcc typically uses 64 bit longs. #elif // ... other platforms ... ... #endif
如果编译器在将来的版本中更改了类型属性,则可以在一个位置编辑类型.
在过去,您还有一个典型的情况,其中int的大小可能是16位或32位,因此您不能简单地在需要DWORD大小参数的代码中使用raw int类型.
因此,为什么你有像LPARAM和WPARAM这样的东西.
它也被用作一种抽象形式.这就是你看到typedef的原因
typedef int Handle;
因为虽然它现在是一个int,但是库作者保留了以后在轨道上更改它的能力,比如void *,或者他们认为必要的任何其他类型.
但客户端代码并不需要特别知道它是一个int,因为这正是它当前所发生的事情.所有客户端需要知道的是将其传递给接受Handle类型的函数.
Typedef还允许在编译时进行配置.例如.某些库可能具有实数的实数类型.它可以用诸如此类的方式定义
#ifdef USE_DOUBLE_PREC typedef double Real; #else typedef float Real; #endif
并且库的用户在编译时可以选择设置/ DUSE_DOUBLE_PREC以获得双精度浮点支持,但重要的是没有库代码需要更改才能工作,因为它已经被抽象化了.
