对不可行的函数模板进行类型扣除 [英] Type deduction for non-viable function templates
问题描述
在他的回答 此问题和评论部分， Johannes Schaub 说，有一个匹配错误，当尝试对需要比已经传递的参数更多的参数的模板类型扣除：
template< class T&
void foo（T，int）;
foo（42）; //模板专用化foo< int>（int，int）不可行
另一个问题，相关的是函数模板的类型扣除是否成功（并且发生替换）：
template<类T>
struct has_no_nested_type {};
//我认为你需要一些特殊化，下面的类模板
//`non_immediate_context`可以被实例化，否则程序是
//形成的，NDR
模板<>
struct has_no_nested_type< double>
{using type = double; };
//使错误不在立即上下文中出现
template< class T>
struct non_immediate_context
{
使用type = typename has_no_nested_type< T> :: type;
}
template< class T>
typename non_immediate_context< T> :: type
foo（T，int）{return {}; }
模板< class T>
bool foo（T）{return {}; }
int main（）
{
foo（42）; //形式良好clang ++ 3.5和g ++ 4.8.2接受它
foo< int>（42）; //形式良好clang ++ 3.5接受它，但不是g ++ 4.8.2
}
为 T == int 实例化第一个函数模板 foo ，替换产生的无效类型不在立即上下文中 foo 。这会导致一个硬错误（这是相关问题的意思。）
但是，当让 foo 推导出其模板参数时，g ++和clang ++同意不会发生实例化。由于 Johannes Schaub解释，这是因为存在匹配错误
问题：什么是匹配错误，以及在标准中指定的位置和位置？ b
$ b
问题：为什么 foo（42）和 foo< int> （42） for g ++？
到目前为止：
[over.match.funcs] / 7和[temp.over]似乎描述了函数模板的重载分辨率细节。后者似乎要求为 foo 替换模板参数。
有趣的是，[over.match.funcs] / 7在检查函数模板（专业化）的可行性之前触发[temp.over] 中描述的过程。
类似地，类型推导不考虑默认函数参数（除非使它们成为非推导的上下文）。似乎不关心可行性，就我所知。
另一个可能重要的方面是如何指定类型扣除。它作用于单个函数参数，但我不知道在哪些参数类型包含/依赖于模板参数（如 T const& ）和那些它们不是（像 int ）。
然而，g ++在显式指定模板参数硬错误），并推导他们（扣除失败/ SFINAE）。为什么？
我总结的过程是在14.8.2.1p1描述的过程
模板参数推导是通过比较每个函数模板参数类型（称为P）和调用的相应参数的类型（称为A）来完成的，如下所述。 / p>
在我们的例子中，我们有P （T，int） A，我们有（int）。对于 T 对 int 的第一对P / A，我们可以匹配 T 到 int （通过14.8.2.5中描述的过程）。但对于第二个pair，我们有 int ，但没有对应。因此，不能对这个对进行扣除。
因此，通过14.8.2.5p2，如果不能对任何P / A对进行类型扣除，...，模板
参数扣除失败。 。
然后你不会到模板参数替换为函数模板的地方。
这可以在标准（IMO）中更准确地描述，但我相信这是如何实现匹配Clang和GCC的实际行为的东西，它似乎是Standardese的合理解释。
In his answer to this question and the comment section, Johannes Schaub says there's a "match error" when trying to do template type deduction for a function template that requires more arguments than have been passed:
template<class T>
void foo(T, int);
foo(42); // the template specialization foo<int>(int, int) is not viable
In the context of the other question, what's relevant is whether or not type deduction for the function template succeeds (and substitution takes place):
template<class T>
struct has_no_nested_type {};
// I think you need some specialization for which the following class template
// `non_immediate_context` can be instantiated, otherwise the program is
// ill-formed, NDR
template<>
struct has_no_nested_type<double>
{ using type = double; };
// make the error appear NOT in the immediate context
template<class T>
struct non_immediate_context
{
using type = typename has_no_nested_type<T>::type;
};
template<class T>
typename non_immediate_context<T>::type
foo(T, int) { return {}; }
template<class T>
bool foo(T) { return {}; }
int main()
{
foo(42); // well-formed? clang++3.5 and g++4.8.2 accept it
foo<int>(42); // well-formed? clang++3.5 accepts it, but not g++4.8.2
}
When instantiating the first function template foo for T == int, the substitution produces an invalid type not in the immediate context of foo. This leads to a hard error (this is what the related question is about.)
However, when letting foo deduce its template-argument, g++ and clang++ agree that no instantiation takes place. As Johannes Schaub explains, this is because there is a "match error".
Question: What is a "match error", and where and how is it specified in the Standard?
Altenative question: Why is there a difference between foo(42) and foo<int>(42) for g++?
What I've found / tried so far:
[over.match.funcs]/7 and [temp.over] seem to describe the overload resolution specifics for function templates. The latter seem to mandate the substitution of template parameters for foo.
Interestingly, [over.match.funcs]/7 triggers the process described in [temp.over] before checking for viability of the function template (specialization). Similarly, type deduction does not to take into account, say, default function arguments (other than making them a non-deduced context). It seems not to be concerned with viability, as far as I can tell.
Another possibly important aspect is how type deduction is specified. It acts on single function parameters, but I don't see where the distinction is made between parameter types that contain / are dependent on template parameters (like T const&) and those which aren't (like int).
Yet, g++ makes a difference between explicitly specifying the template parameter (hard error) and letting them be deduced (deduction failure / SFINAE). Why?
What I've summarized is the process described at 14.8.2.1p1
Template argument deduction is done by comparing each function template parameter type (call it P) with the type of the corresponding argument of the call (call it A) as described below.
In our case, we have for P (T, int) and for A, we have (int). For the first pair of P/A, which is T against int, we can match T to int (by the process described in 14.8.2.5). But for the second "pair", we have int but have no counterpart. Thus deduction cannot be made for this "pair".
Thereby, by 14.8.2.5p2, "If type deduction cannot be done for any P/A pair, ..., template argument deduction fails.".
You then won't ever come to the point where you substitute template arguments into the function template.
This can all probably described more precisely in the Standard (IMO), but I believe this is how one could implement things to match the actual behavior of Clang and GCC and it seems a reasonable interpretation of the Standardese.
这篇关于对不可行的函数模板进行类型扣除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
