API 特定类型定义（例如 GLsizei GLint GLvoid）的用途是什么？
我在 c 和 c++ 代码中随处可见这一点。基本类型通常使用库前缀/后缀进行类型定义。这背后的原因是什么？这是好习惯吗？我的程序应该自己做类似的事情吗？
乍一看，它似乎使代码的可读性降低了一点。您必须花点时间在脑海中将 GLint 转换为 int，这是一个简单的示例。
对我来说，像 UINT 这样的东西会做得更多，至少这会将 unsigned int 缩短为四个字母。
【问题讨论】：
这不是关于缩短名称，而是关于可移植性。不同的平台需要对这些内容进行不同的 typedef。
在 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 大小参数的代码中简单地使用原始 int 类型.
因此你有LPARAM和WPARAM之类的东西。
它也被用作一种抽象形式。这就是为什么你会看到类似的 typedef
typedef int Handle;
因为虽然它现在是 int，但库作者保留稍后将其更改为其他任何内容的能力，例如 void *，或他们认为必要的任何其他类型。
但是客户端代码不需要知道它是一个int，因为这正是它目前的情况。客户端需要知道的只是将其传递给接受Handle 类型的函数。
Typedefs 还允许在编译时进行配置。例如。一些库可能有一个Real 实数类型。可以这样定义
#ifdef USE_DOUBLE_PREC
typedef double Real;
#else
typedef float Real;
#endif
并且库的用户可以在编译时选择设置/DUSE_DOUBLE_PREC 以获得双精度浮点支持，但重要的是无需更改库代码即可使其工作，因为它已被抽象。
【讨论】：
在大多数情况下，当一个库定义了除了标准中类似命名类型之外没有保证属性的基本类型（想想INT、GLint、gint、LPSTR、u32、u_int等），目的是：
基于我最喜欢的原则之一“永远不要将可以用愚蠢来充分解释的事情归咎于恶意”，您可能会选择第 2 条，但这完全取决于您。
就个人而言，每当编写此类 API 时，我都会丢弃特定于库的类型并使用正确的自然类型（int、char *、uint32_t 等）代替它们。如果我需要的话，可以很容易地调整我的代码以在没有库的情况下使用，并且代码对于不熟悉库的人来说更具可读性。
【讨论】：
GLint 的一些荒谬想法强加给它们而不是使用它们表示整数的本地方式会使该语言的用户大为震惊。 C 应该得到同样的尊重。
GLint 的荒谬想法。定义 GLint 的全部意义在于你不必须实际考虑在平台 XYZ 上常规 int 是 16 字节还是 32 字节还是 64 字节，这允许您以可移植的方式编写代码。
GLint 的目的始终是 32 位，那么他们为它选择了一个非常糟糕的名称。阅读它，我希望它（如 Windows 的 INT 和 glib 的 gint）是自然大小的特定于平台的整数类型，可能总是定义为 int。 @Mads：如果您阅读我的回答，您会发现我建议 2 在提供它们之后是更好的解释。但是在某些情况下（肯定是 glib），它确实是 1。
如果需要以某种方式更改底层类型，它可以在一个地方更改 typedef，而不是在整个代码库中搜索和替换。然而，我也发现它比任何东西都更“噪音”，并且很少在现实生活中看到它需要它。
如果您碰巧在游戏中工作并且可能需要将您的游戏从/移植到 Nintendo DS，我见过的唯一一个不错的例子是浮点数，因为 DS 本身就可以使用定点数字。在这种情况下，您有一个特殊的浮点类型定义，因此它确实被类型定义为大多数平台上的浮点数和 DS 上的特殊定点类。
【讨论】：