为什么有人会使用 gboolean (GLib) 而不是 bool 类型？

Question

我一直在阅读一些使用 gtk+ 的代码，并且遇到过像 gboolean 和 gunichar 这样的类型。

只要我能理解使用gunichar 而不是wchar_t (glib gunichar and wchar_t) 的意义，我就无法真正理解使用gboolean 而不是bool 的意义。

问题：使用gboolean 代替bool 有什么意义？除了注意代码风格的一致性之外，还有什么其他的吗？

如果它用于一般一致性，对我来说不会那么奇怪（如果一个人决定使用GLib，一个人会更喜欢使用那里定义的类型）。然而，该代码的作者使用int 而不是gint。是作者粗心吗？

---

只是添加更多细节（official GLib as a reference）：

• gunichar 定义为typedef guint32 gunichar

• guint32 定义为typedef unsigned int guint32

• gboolean 定义为typedef gint gboolean

• gint 定义为typedef int gint

Answer 1

统一性和可维护性。如果在未来的某个时刻引入了新的 utf8char 类型，只需更改 typedef 并重新编译即可，而无需通过数千行代码来修补每次使用。

还要考虑到 GLib 旨在适用于各种编译器，但并非所有编译器都完全符合最新规范。例如，不能假设 bool、wchar_t 和固定大小类型的可用性，因为它们都带有 C99 和 C11。此外，GLib 的开发始于 1998 年（正如您从 contributors graph 中看到的那样），当时 C99 仍处于草案阶段，这些功能甚至都不是标准的。

Answer 2

最近发现这不仅仅是关于一致性；在处理 big endian 平台时实际上需要注意。

在迄今为止测试过的大端平台上（PowerPC32、Sparc64 等）g_option_context_parse() 将无法处理用 C99 _Bool 声明的参数，就好像相关选项被完全忽略了一样。切换到gboolean，一切都恢复正常了。小端平台不存在此问题。

我不确定是不是故意的，但是G_OPTION_ARG_NONE类型参数的内部解析都是使用gboolean处理的，就占用字节大小而言相当于原生整数，而_Bool占用1仅字节。可能这解释了大端环境下的问题。