在Itanium c++ ABI中，为什么模板函数的混乱名称不能解析依赖类型?

In the Itanium C++ ABI, why does the mangled name for template functions not resolve dependent typedefs?

本文关键字：不能 混乱 类型 依赖 函数 ABI c++ Itanium 为什么      更新时间：2023-10-16

例如:

template <typename T>
struct foo
{
    using bar = int;
};
// _Z3bazi
void baz(foo<int>::bar quux) {
}
template <typename T>
void baz(typename foo<T>::bar quux) {
}
// _Z3bazIiEvN3fooIT_E3barE
template void baz<int>(foo<int>::bar quux);

为什么破损的baz<int>会提到foo ?为什么不是_Z3bazIiEvi ?

这显然是c++ 17 std::default_order<T>提案搁浅的原因。

问题来自于ABI中的<unresolved-name>构造。为什么我们要使用一个未解析的名称呢?这都是关于声明匹配和重载的。c++ 14§14.5.6.1/3注释，

两个不同的函数模板可以有相同的函数返回类型和函数形参表，即使单独的重载解析不能区分它们。

你可以在另一个文件中有另一个函数，

template <typename T>
void baz(int quux) { std::abort(); }

尽管这个签名不能和平地共存于同一个文件中——由于重载的模糊性，它不能被命名——但它可以存在于不同的文件中，所以它需要一个不同的mangling

(即使这种共存级别也不是所有模板的标准所保证的。编译器使用函数模板声明的确切形式来执行声明匹配是一个QOI问题，因此将声明复制粘贴到定义中将倾向于提供精确匹配，而不会与解析到相同签名的另一个函数模板发生意外冲突。看到§14.5.6.1/5-6。)

至于default_order的队列，问题是模板id隐式地从模板中提取默认参数。因此，用户可能仅仅通过提到std::set就无意中在签名中拥有一个依赖的类型名。

相关文章：