为什么有人会使用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声明的参数，就好像完全忽略了relevent选项一样。切换到gboolean，一切都会恢复。小端字节序平台中不存在此问题。

我不确定这是否是故意的行为，但是G_OPTION_ARG_NONE类型参数的内部解析都是使用gboolean处理的，这在占用字节大小方面等效于本机整数，而{ {1}}仅占用1个字节。也许可以解释大端环境下的问题。