为什么有人会使用 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，然后一切又恢复正常了。 little endian 平台不存在此问题。

不知道是不是故意的，G_OPTION_ARG_NONE类型参数的内部解析都是用gboolean处理的，在占用字节大小上等同于原生整型，而 _Bool 只占用 1 个字节。大概就是大端环境下的问题了。