GTK数据类型与基本数据类型

Question

我开始为一些小项目摆弄GTK+。

GLib定义了一系列数据类型，如gint gpointer等，它们只是基本数据类型的类型定义(gint是int的typedef，gpointer是void*等的类型定义)。

现在，假设我有一个函数或类，它根本不使用GTK。我真的很想使用基本数据类型，这样即使不包含GTK头，我也可以在其他地方重用类/函数。

另一方面，我发现在代码中混合使用gint和int是很难看的，因为它们实际上是一回事。

总而言之，我想知道何时使用其中一种或另一种是否有标准的做法，或者是否应该随意混合它们……

Answer 1

我在很多第三方库中处理过这个问题，他们都希望为整数、浮点数、长整型、短整型、字节别名而不是字符等使用自己的类型别名。

这是非常烦人的。这样做通常是为了确保可移植性，但最终会给每个库提供自己的标准。

我发现这里最令人不快的是从耦合的角度来看。我可能有一个通用的网格界面，它应该与任何渲染问题解耦。然而，它的一些数据可能会被直接传递给一个OpenGL函数，该函数希望假定我们传递的整数的大小将与sizeof(GLint)匹配。

在某些情况下，这不仅仅是美学上的。在这个网状头中包含GL头可能是不合理的，因为它可能是广泛使用的软件开发工具包的一部分，不应该需要对使用它的第三方插件编写器的编译时依赖。

然而，可移植性是一个问题。我设法在一个非常大规模的遗留C代码库中度过了一个噩梦般的场景，其中隐含的假设贯穿于整个代码库，即sizeof(int) == sizeof(void*)。为了将这个代码库移植到64位，我们花了几年时间大海捞针。

多年来，我个人决定的是开始偏爱普通的旧的无别名数据类型。我也喜欢只使用带符号的整数，例如，我发现过去在通过容器的基本循环中甚至要避免警告，其中一些人会使用int，其他人使用unsigned int，其他人使用size_t等来指示所包含的元素的数量，这很麻烦。至少就我个人而言，我发现在没有很好的理由不这样做的情况下，仅仅偏爱int就可以减少维护时间。

为了在一些平台上缓解潜在的最坏情况，例如，我倾向于在代码周围自由地散布断言，这些断言假设这两者是相等的：assert(sizeof(int) == sizeof(GLint));。这应该会大大减轻我之前从32位移植到64位时所面临的那种噩梦般的场景带来的痛苦。它还明确表达了这些假设。

我发现这为我的案例建立了一个舒适的平衡。当然，这都是主观的，根据您的用例可能会有很大的不同。但这是一种可能的解决方案，它可以让您在所有这些第三方库的情况下，越来越多地偏爱普通的旧的未别名数据类型，并且如果您的假设在某些平台上不再正确，也不会面临最坏的情况。