我想将垃圾收集语言（具体来说，它使用古老的 Boehm libgc）与 glib 系列 API 接口。
glib 和 gobject 在内部使用引用计数来管理对象生命周期。包装这些的正常方法是使用垃圾收集的对等对象，该对象保存对 glib 对象的引用，并在对等点完成时删除该引用；这意味着当应用程序使用对等点时，glib 对象保持活动状态。我之前已经这样做过，并且它有效，但它非常痛苦并且有其自身的问题（例如生成同一底层对象的两个对等点）。
鉴于我已经承担了垃圾收集器的所有开销anyway，理想情况下我想做的是简单地关闭 glib 的引用计数并使用垃圾收集器来处理所有事情。这将无限简化界面并有望提高性能。
从表面上看，这似乎相当简单 --- 将垃圾收集器终结器连接到 glib 对象终结器，并将 ref 和 unref 函数重写为 noops --- 但进一步的调查表明，事情远不止这些： glib例如，非常喜欢保留自己的分配器池，当然我让它这样做，垃圾收集器假设池中的所有内容都是活动的，并且会泄漏。
说服 glib 使用 libgc 实际上可行吗？如果是这样，我可能还会遇到哪些其他问题？什么样的 glib 性能影响会迫使所有分配都通过 libgc 生成（而不是使用当前 glib 中的优化分配器）？
（glib 文档确实说它应该与垃圾收集器干净地接口......）
http://mail.gnome.org/archives/gtk-devel-list/2001-February/msg00133.html http://mail.gnome.org/archives/gtk-devel-list/2001-February/msg00133.html老了
但仍然相关。
学习语言绑定如何工作（代理对象、切换引用）可能有助于思考这个问题。
更新：哦，从 Boehm GC 听到的消息中，我认为您正在尝试用 GC 替换 g_malloc 等，就像那篇旧文章中那样。
如果您正在进行语言绑定（而不是 GC'ing C/C++），那么是的，这是非常可以实现的。 gjs (SpiderMonkey JavaScript) 代码库是一个很好且易于管理的示例。
基本思想是，您将拥有一个“保存”GObject 的代理对象，并且通常具有对该 GObject 的唯一引用。但是，唯一的复杂性是切换引用：http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html
您必须将代理对象存储在 GObject 上，以便可以将其取回（假设有人执行 widget.get_parent()，那么您需要通过从 C GObject 检索它来返回之前设置为父对象的同一对象） 。显然，您还必须能够从代理对象转到 C 对象。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
