我有一个实质性的C项目，现在已经使用Boehm GC一段时间了;它是从头开始构建的，从第一天开始就使用了Boehm GC，它的类型分配行为是众所周知的。
目前，它使用GC_MALLOC()和GC_MALLOC_ATOMIC()，并且具有可接受的（可容忍的）性能。但由于它的所有类型都是众所周知的，并且项目通常与C生态系统的其他部分隔离（它不会链接libc之外的任何内容），因此将项目切换为主要使用{似乎并非不合理{1}}。许多项目的类型混合和匹配原始值和指针，所以理论上，这个应该通过允许收集器在所有分配的类型上精确而不是保守而在集合期间提供性能提升通过它。 （它可能不是性能提升的很多，但我仍然希望尽可能地好好收集垃圾收集器。）
尽管如此，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()的完美候选者，但这些警告消息的数量和范围仍然让我暂停，他们几乎似乎暗示GC_malloc_explicitly_typed()函数将在删除某些内容以支持“更好”的界面。所以我的问题很简单：
是否有人使用explicitly_typed发现任何未说明或非明显的缺点？