我有一个使用 Boehm GC 一段时间的大型 C 项目；它是从头开始构建的，从一开始就使用 Boehm GC，它的类型分配行为是众所周知的。
目前，它使用GC_MALLOC()and GC_MALLOC_ATOMIC()，并且它具有可接受的（可容忍的）性能。但是因为它的所有类型都是众所周知的，并且该项目通常与 C 生态系统的其余部分隔离（它不链接 libc 之外的任何内容），所以将项目切换为主要使用GC_malloc_explicitly_typed(). 该项目的许多类型混合匹配原始值和指针，因此理论上，这应该通过允许收集器在通过它分配的所有类型上精确而不是保守来提高收集期间的性能。（这可能不会有很大的性能提升，但我仍然希望对垃圾收集器尽可能好。）
也就是说，gc_typed.h顶部有关于使用的各种警告消息GC_malloc_explicitly_typed()：
/*
* Some simple primitives for allocation with explicit type information.
* Facilities for dynamic type inference may be added later.
* Should be used only for extremely performance critical applications,
* or if conservative collector leakage is otherwise a problem (unlikely).
* Note that this is implemented completely separately from the rest
* of the collector, and is not linked in unless referenced.
* This does not currently support GC_DEBUG in any interesting way.
*/
和这个：
/* Returns a conservative approximation in the */
/* (unlikely) case of insufficient memory to build */
/* the descriptor. Calls to GC_make_descriptor */
/* may consume some amount of a finite resource. This */
/* is intended to be called once per type, not once */
/* per allocation. */
我真的不相信这些对我来说都是问题，而且我的代码对性能至关重要，而且收集器在我的一些分析中确实很热门。我认为我不需要GC_DEBUG——至少，我从来没有觉得需要调试堆。我对GC_make_descriptor()需要分配的每种类型进行调用都没有问题，并且在程序启动时以可预测的常数次数调用该函数也没有问题。
看起来我的代码是 using 的完美候选者GC_malloc_explicitly_typed()，但这些警告消息的数量和范围仍然让我犹豫不决，它们似乎暗示该explicitly_typed函数将在某个时候被删除以支持“更好”的界面。所以我的问题很简单：
有没有人GC_malloc_explicitly_typed()发现使用它有任何未说明或不明显的缺点？