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

Question

我一直在阅读一些使用的代码,gtk+我遇到了类似gboolean和的类型gunichar.

只要我能理解使用gunichar而不是wchar_t(glib gunichar和wchar_t),我就无法真正理解使用gboolean而不是使用bool.

问题:用什么gboolean代替bool？有没有什么比仅仅注意代码风格的一致性？

如果它被用于一般的一致性(如果一个人决定使用GLib,人们更愿意使用那里定义的类型),那对我来说就不会那么奇怪了.但是,该代码的作者使用int而不是gint.作者是不是很粗心？

---

只是添加更多细节(官方GLib作为参考):

• 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年(正如您可以从贡献者图中看到的那样),当C99仍处于草案状态时,这些功能甚至不是标准的.

Answer 2

最近发现这不仅仅关乎一致性；还关乎一致性。在处理大端平台时实际上需要注意。

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

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