glib 是否可以以不显眼的方式使用？答案

【问题标题】：Is glib usable in an unobtrusive way?glib 是否可以以不显眼的方式使用？
【发布时间】：2013-07-01 03:09:58
【问题描述】：

我一直在寻找标准 C 库之上的 good general-purpose library for C，并看到了一些使用 glib 的建议。它在您的代码中有多“突兀”？为了解释我所说的突兀，我在reference manual 中注意到的第一件事是basic types section，心里想，“什么，我要开始使用gint、gchar 和gprefixing geverything gin gmy gcode 知道吗？”

更一般地说，您是否可以只在本地使用它，而代码中的其他函数或文件不必知道它的用途？它是否会强制对您的代码进行某些假设，或对您的编译/链接过程施加限制？全局数据结构在运行时会占用大量内存吗？等等

【问题讨论】：

能否请亲密的战士回到拖钓维基百科以删除文章而不是干扰 SO？这个问题是完全可以回答的，并且有很多合理的方式来解释“不引人注目”，这样问题就有了客观的答案。
投票重新开放，我们在 SO 上拥有大量 C 专业知识，可以用专业知识而不是意见来回答这样的问题，现有答案就是证明。

标签： c coding-style glib

【解决方案1】：

关于 glib 最令人信服的一点是，任何使用它的程序或库都无法抵抗资源耗尽。当malloc 失败时，它会无条件调用abort，您无法解决此问题，因为整个库都是围绕其内部分配函数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，并且做同样的事情：它只是返回。

【讨论】：

真的吗？这太可怕了。用其他东西动态替换 abort() 会帮助我吗？ ...（或者我应该考虑做这些事情。）
否，因为 glib 中的代码不准备获取 NULL 返回值。 g_malloc的接口约定是不成功就永远不返回，满足这个约定的唯一方法就是不成功就终止程序。原则上，您可以捕获 SIGABRT 和 longjmp，但随后您会将正在被操作的对象置于不确定状态，因此进一步访问它们将是潜在的危险。
那么，glib 是不可能的。谢谢:-(
+1 打破了我认为 glib 是由 C 专家编写的假设。
是的。具有讽刺意味的是，glib 最初是作为 GIMP 的一部分设计的，这几乎是当malloc 失败时拥有abort 的最糟糕的程序，而malloc 很可能由于分配大量资源而失败...

【解决方案2】：

我已经专业使用 GLib 超过 6 年了，我对它赞不绝口。它非常轻量，有很多很棒的实用程序，如列表、哈希表、rand 函数、io 库、线程/互斥体/条件，甚至 GObject。一切都以便携的方式完成。事实上，我们已经在 Windows、OSX、Linux、Solaris、iOS、Android 和 Arm-Linux 上编译了相同的 GLib 代码，在 GLib 方面没有任何问题。

就突兀性而言，我绝对“买进了 g”，毫无疑问，这对于快速生成稳定、可移植的代码非常有利。尤其是在编写高级测试时。

如果 g_malloc 不适合您的目的，只需使用 malloc 代替，这当然适用。

【讨论】：

@R. 在他的 [answer here]((stackoverflow.com/a/17448240/1593077) 中的声明怎么样，glib 在自己进行 malloc 时假定分配成功并在分配成功时中止不是这样吗？
另外，至于“购买 g”，您是指使用您的代码的任何人都需要面向 glib 的风格，还是只是您自己经常使用该库这一事实？如果是前者，那么这对我来说是个问题，因为我在一个小组中工作，并且我可以在其他人的代码中更改的内容有限。
@HavardGraff：所有的 glib 函数内部都使用g_malloc 来获取内存。不使用g_malloc直接也没关系；只要你在 glib 中使用任何需要分配内存的函数，它就会调用g_malloc，然后你就完蛋了。
@R：大部分内部使用slice-allocator，在大多数情况下优于malloc。并且在内存不足时通过调用中止来“搞砸”并没有普遍的真理，它是一种实现选择，意见/要求不同于编写超防御性代码以“提前失败”。内存不足时调用 abort 是您可以选择接受或不接受的合同，如果您接受，GLib 是一个很好的选择。（说 GLib 开发人员缺乏 C 知识是一种非常粗鲁和轻率的评论，并不酷）
@HavardGraff：如果调用各种glib函数可以abort()我的进程，那我就完蛋了。我需要编写（除其他外）不会崩溃的应用程序或守护进程。并且通用库不能随意破坏进程。

【解决方案3】：

当然你可以“在别处忘掉它”，当然除非那些其它地方以某种方式与 glib 代码交互，那么就有联系（而且，可以说，你并不是真正的“别处”）。

您不必使用带有g 前缀的常规类型（gchar、gint 等）；它们保证与char、int 等相同。例如，您永远不需要向/从 gint 转换。

我认为其目的是应用程序代码永远不应该使用gint，它只是包含在内以便 glib 代码可以更加一致。

【讨论】：

Typesdefs 包括在内，因为 glib 是在 stdint.h 出现之前创建的。所以这是因为遗留问题：stackoverflow.com/a/38552322/2587286