Сообщение Re: unresolved overloaded function type от 02.02.2022 17:16
Изменено 02.02.2022 17:32 Андрей Тарасевич
Re: unresolved overloaded function type
Здравствуйте, SergH, Вы писали:
SH>Так и должно быть? Можно как-то просто объяснить, почему?
Шаблонная лямбда порождает НЕшаблонный класс с шаблонным методом `operator ()`. Ключевой момент тут в том, что тип лямбды, т.е. самого closure-объекта — НЕшаблонный. Таким образом при вызове функции
никаких трудностей с дедукций шаблонного параметра `F` у компилятора не возникает — оно определен однозначно. Дедукция `auto` для вашей лямбды будет делаться позже — в точке вызова `operator ()`, то есть в точке `f(1, 2);`, где все тоже однозначно.
Для варианта
ситуация совсем иная — дедукция всех шаблонных аргументов (и `F` для `func` и `T` для `test`) должна быть сделана немедленно в этой точке. А это невозможно.
SH>Так и должно быть? Можно как-то просто объяснить, почему?
Шаблонная лямбда порождает НЕшаблонный класс с шаблонным методом `operator ()`. Ключевой момент тут в том, что тип лямбды, т.е. самого closure-объекта — НЕшаблонный. Таким образом при вызове функции
test([](auto x, auto y) { func(x, y);});
никаких трудностей с дедукций шаблонного параметра `F` у компилятора не возникает — оно определен однозначно. Дедукция `auto` для вашей лямбды будет делаться позже — в точке вызова `operator ()`, то есть в точке `f(1, 2);`, где все тоже однозначно.
Для варианта
test(func);
ситуация совсем иная — дедукция всех шаблонных аргументов (и `F` для `func` и `T` для `test`) должна быть сделана немедленно в этой точке. А это невозможно.
Re: unresolved overloaded function type
Здравствуйте, SergH, Вы писали:
SH>Так и должно быть? Можно как-то просто объяснить, почему?
Шаблонная лямбда порождает НЕшаблонный класс с шаблонным методом `operator ()`. Ключевой момент тут в том, что тип лямбды, т.е. самого closure-объекта — НЕшаблонный. Таким образом при вызове функции
никаких трудностей с дедукций шаблонного параметра `F` у компилятора не возникает — оно сразу определен однозначно. Дедукция `auto` для вашей лямбды будет делаться позже совсем в другом месте — в точке вызова `operator ()`, то есть в точке `f(1, 2);`, где все тоже однозначно.
Для варианта
ситуация совсем иная — дедукция всех шаблонных аргументов (и `F` для `func` и `T` для `test`) должна быть сделана немедленно в этой точке. А это невозможно.
SH>Так и должно быть? Можно как-то просто объяснить, почему?
Шаблонная лямбда порождает НЕшаблонный класс с шаблонным методом `operator ()`. Ключевой момент тут в том, что тип лямбды, т.е. самого closure-объекта — НЕшаблонный. Таким образом при вызове функции
test([](auto x, auto y) { func(x, y);});
никаких трудностей с дедукций шаблонного параметра `F` у компилятора не возникает — оно сразу определен однозначно. Дедукция `auto` для вашей лямбды будет делаться позже совсем в другом месте — в точке вызова `operator ()`, то есть в точке `f(1, 2);`, где все тоже однозначно.
Для варианта
test(func);
ситуация совсем иная — дедукция всех шаблонных аргументов (и `F` для `func` и `T` для `test`) должна быть сделана немедленно в этой точке. А это невозможно.