std::inserter未遵循自定义比较器问题排查（疑似编译器Bug）

这真是个棘手的问题！我之前也踩过类似模板推导相关的坑，结合你的描述和GCC 7.3.0的版本特性，除了编译器本身的bug之外，还有几个可能的原因值得排查：

• 头文件包含不完整：std::inserter和std::insert_iterator的完整定义都在<iterator>头文件中。如果你的代码只是间接通过其他头文件（比如<set>或<algorithm>）引入了部分定义，编译器可能会使用不完整的推导逻辑，导致错误地将容器类型推导为默认比较器的std::set<T, std::less<T>>。建议你在代码中显式添加#include <iterator>，确保所有相关模板都能正确解析。

• ADL（参数依赖查找）的意外匹配：虽然概率不高，但如果你的代码中存在其他命名空间下的inserter模板函数，编译器可能会通过ADL优先匹配到这个自定义版本，而非std::inserter。比如，如果你在某个业务命名空间下定义了一个针对std::set的inserter，且没有明确限定std::前缀，就可能出现这种混淆。可以确认是否有其他地方的隐式引入干扰了std::inserter的调用。

• 模板参数推导的边缘场景：GCC 7.3.0是2018年发布的旧版本，在处理依赖模板参数的容器类型推导时，可能存在不完善的地方。虽然你的代码中out是明确的std::set<T, C>，但编译器在推导std::inserter的模板参数时，可能没有正确捕获到C的类型，而是 fallback 到了std::set的默认比较器参数。这种情况下，显式指定std::inserter的模板参数可以规避问题：

  std::inserter<std::set<T, C>>(out, out.end())
  

  如果这样修改后问题消失，基本可以确认是推导阶段的问题。

• 自定义比较器的隐式转换干扰：如果你的自定义比较器C存在隐式转换到std::less<T>的逻辑（比如继承了std::less<T>或者定义了相关转换运算符），可能会导致编译器在推导时产生歧义。不过这种情况通常会引发编译错误，而非偶发的运行时行为，所以可能性较低，但可以检查一下比较器的实现是否存在这类情况。

验证建议 #

1. 显式添加#include <iterator>，重新编译测试；
2. 在使用std::inserter时显式指定模板参数，看问题是否消失；
3. 检查代码中是否存在其他命名空间下的inserter实现；
4. 尝试升级到GCC 8及以上版本，新版本修复了很多模板推导的旧bug，若问题消失则进一步确认是老版本编译器的问题。

内容的提问来源于stack exchange，提问作者Jackson