我在标准 C 库之上为 C寻找一个好的通用库，并且看到了一些使用glib的建议。它在您的代码中有多“突兀”？为了解释我所说的突兀，我在参考手册中注意到的第一件事是基本类型部分，我在想，“什么，我要开始使用gint,gchar和 gprefixing geverything gin gmy gcode gnow 吗？”
更一般地说，您是否可以仅在本地使用它，而代码中的其他函数或文件不必知道它的使用？它是否会强制对您的代码进行某些假设，或对您的编译/链接过程施加限制？全局数据结构在运行时会占用大量内存吗？等等
关于 glib 最令人信服的一点是，任何使用它的程序或库都无法抵抗资源耗尽。abort它在失败时无条件调用，malloc您无法解决此问题，因为整个库都是围绕其内部分配函数g_malloc“不会失败”的概念设计的
至于丑陋的“g”类型，你绝对不需要任何演员表。这些类型 100% 等同于标准类型，基本上只是 glib 早期（错误）设计的产物。不幸的是，glib 开发人员对 C 缺乏很多了解，正如这个常见问题所证明的那样：
为什么要使用 g_print、g_malloc、g_strdup 和其他 glib 函数？
“关于 g_malloc()、g_free() 和兄弟函数，这些函数比它们的 libc 等效函数安全得多。例如，g_free() 仅在使用 NULL 调用时返回。
（来源：https ://developer.gnome.org/gtk-faq/stable/x908.html ）
仅供参考，free(NULL)是完全有效的 C，并且做同样的事情：它只是返回。
我已经专业使用 GLib 超过 6 年了，对它只有赞美之词。它非常轻量级，有很多很棒的实用程序，如列表、哈希表、rand 函数、io 库、线程/互斥体/条件，甚至 GObject。一切都以便携的方式完成。事实上，我们已经在 Windows、OSX、Linux、Solaris、iOS、Android 和 Arm-Linux 上编译了相同的 GLib 代码，在 GLib 方面没有任何问题。
就突兀性而言，我绝对“买进了 g”，毫无疑问，这对于快速生成稳定、可移植的代码非常有利。也许特别是在编写高级测试时。
如果 g_malloc 不适合您的目的，只需使用 malloc 代替，这当然适用于所有这些。
当然，您可以“在其他地方忘记它”，当然除非那些其他地方以某种方式与 glib 代码交互，否则就会存在联系（并且，可以说，您并不是真正的“其他地方”）。
您不必使用带有前置g(gchar等gint) 的常规类型；它们保证与 , 相同char，int依此类推。例如，您永远不需要投射到/从gint。
我认为其意图是应用程序代码永远不应该使用gint，它只是被包含在内，以便 glib 代码可以更加一致。