是否可以仅对程序的一部分使用 Boehm 垃圾收集器？
我读过 LinuxJournal 中的文章，内容涉及 Boehm-Demers-Weiser 垃圾收集器库。我很感兴趣在我的库中使用它而不是我自己的引用计数实现。
我只有一个问题：是否可以仅对我的共享库使用 gc，而仍然在主应用程序中使用 malloc/free？我不太明白 gc 如何检查堆，所以我担心在这种情况下 gc 的性能以及可能的副作用。
I've read article in LinuxJournal about Boehm-Demers-Weiser garbage collector library. I'm interesting to use it in my library instead of my own reference counting implementation.
I have only one question: is it possible to use gc only for my shared library and still use malloc/free in the main application? I'm not quite understand how gc checks the heap so I'm worrying about performance of gc in that case and possible side effects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
手册中的示例指出：
更具体地说，对于 C++：
查看手册中的源代码，您会发现垃圾收集的内存是通过特定的调用来处理的，因此，管理是单独处理的（由收集器或手动处理）。因此，只要您的库正确处理其内部并且不暴露收集的内存，就应该没问题。你不知道其他库如何管理它们的内存，你也可以使用它们，不是吗？ :)
The example in the manual states:
And more specifically for C++:
Looking at the source code in the manual you will see the garbage-collected memory is handled through specific calls, hence, the management is handled separately (either by the collector or manually). So as long your library handles its internals properly and doesn't expose collected memory, you should be fine. You don't know how other libraries manage their memory and you can use them as well, don't you? :)
我相信是的，您可以混合两者：但是如果您使用普通分配器分配一个对象，该分配器保存对您使用垃圾收集分配器分配的对象的引用，那么该引用将不可见到 GC，以便对象可能被提前释放。
如果您需要，请查看 GC_MALLOC_UNCOLLECTABLE 函数规范GC 考虑内存中不应收集的引用。
总而言之，是的，但是如果你不小心，这里就会出现龙！
I believe that yes, you can mix the two: however if you allocate an object with the normal allocator that holds a reference to an object you allocate with the garbage collecting one, then that reference will not be visible to the GC so that object may be prematurely deallocated.
Have a look at the GC_MALLOC_UNCOLLECTABLE function specification if you need the GC to take account of references in memory that shouldn't be collected.
In summary, yes, but here be dragons if you aren't careful!