通用 lambda、重载、std::is_invocable 和 SFINAE - GCC 和 Clang 之间的不同行为
Generic lambdas, overloading, std::is_invocable and SFINAE - different behavior among GCC and Clang
问题
我写了一段复杂的模板代码,可以编译with GCC 8.2.1, but not with Clang 7.0(代码和错误链接)。
我认为这可能是 this Q&A 的暗示,但我看不到它。
动机
我正在写一个 class,我希望它可以用两个不同类型的可调用对象构造,但也可以省略其中一个,即:
my_class(callable_1);
my_class(callable_2);
my_class(callable_1, callable_2);
那应该没有问题。但是,为什么不允许 callable_1
和 callable_2
成为函数模板(或带有 operator()
模板的函子)。也就是说,我想要这个(或者至少最初想要):
my_class([](auto arg) {});
my_class([](auto arg) {});
my_class([](auto arg) {}, [](auto arg) {});
如您所见,不幸的是,这两个可调用对象具有相同的签名,因此我们需要以某种方式消除它们之间的歧义。我能想到的第一种方法(也是这个问题所涉及的方法)是向其中一个一元重载添加一个 "tag" 参数:
my_class([](auto arg) {});
my_class([](auto arg) {}, callable_2_tag());
my_class([](auto arg) {}, [](auto arg) {});
对我来说,这看起来可以接受,但我想出了更好的解决方案:
- 在第二个可调用对象的签名(最后一个参数或 return 类型)中使用标签(如果不明确则可选)
- 使第二个构造函数重载为不同名称的非成员函数或
static
成员函数
不过,我还是想知道为什么使用我的初始方法的两个编译器在行为上存在差异,哪个是正确的(或者两者是否正确)。
代码:
为简单起见,我已将构造函数重载转换为常规 my_class
函数重载。
#include <iostream>
#include <type_traits>
// parameter types for callbacks and the tag class
struct foo { void func1() {} };
struct bar { void func2() {} };
struct bar_tag {};
// callable checks
template <typename Func>
static constexpr bool is_valid_func_1_v = std::is_invocable_r_v<void, Func, foo>;
template <typename Func>
static constexpr bool is_valid_func_2_v = std::is_invocable_r_v<void, Func, bar>;
// default values
static constexpr auto default_func_1 = [](foo) {};
static constexpr auto default_func_2 = [](bar) {};
// accepting callable 1
template <typename Func1, std::enable_if_t<is_valid_func_1_v<Func1>>* = nullptr>
void my_class(Func1&& func_1)
{
my_class(std::forward<Func1>(func_1), default_func_2);
}
// accepting callable 1
template <typename Func2, std::enable_if_t<is_valid_func_2_v<Func2>>* = nullptr>
void my_class(Func2&& func_2, bar_tag)
{
my_class(default_func_1, std::forward<Func2>(func_2));
}
// accepting both
template <
typename Func1, typename Func2,
// disallow Func2 to be deduced as bar_tag
// (not even sure why this check did not work in conjunction with others,
// even with GCC)
std::enable_if_t<!std::is_same_v<Func2, bar_tag>>* = nullptr,
std::enable_if_t<is_valid_func_1_v<Func1> &&
is_valid_func_2_v<Func2>>* = nullptr>
void my_class(Func1&& func_1, Func2&& func_2)
{
std::forward<Func1>(func_1)(foo());
std::forward<Func2>(func_2)(bar());
}
int main()
{
my_class([](auto foo) { foo.func1(); });
my_class([](auto bar) { bar.func2(); }, bar_tag());
}
对于 Clang,这将导致:
error: no member named 'func1' in 'bar'
my_class([](auto foo) { foo.func1(); });
~~~ ^
...
note: in instantiation of variable template specialization
'is_valid_func_2_v<(lambda at prog.cc:41:14)>' requested here
template <typename Func2, std::enable_if_t<is_valid_func_2_v<Func2>>* = nullptr>
^
这里发生了什么? 替换失败是错误吗?
编辑: 我完全无知地认为 std::enable_if
的谓词中的错误也会被沉默...那就是 不是替换失败。
修复:
如果我将 SFINAE 作为函数参数,Clang 可以很好地处理它。 我不知道为什么将检查从模板参数推导阶段推迟到重载解析阶段会有所不同。
template <typename Func2>
void my_class(Func2&& func_2, bar_tag,
std::enable_if_t<is_valid_func_2_v<Func2>>* = nullptr)
{
my_class(default_func_1, std::forward<Func2>(func_2));
}
总而言之,我对通用性的投入可能超出了我的知识范围,现在我正在为此付出代价。那我错过了什么?细心的 reader 可能会注意到突然出现的一些附带问题,但我不想回答所有这些问题。最后,如果可以制作更简单的 MCVE,我很抱歉。
根据我的理解,您没有完全正确地使用 SFINAE - 如果您尝试使用 Func == decltype([](auto foo) { foo.func1(); }
调用 std::is_invocable_r_v<void, Func, bar>;
,您将遇到编译器错误,因为 lambda 中的 auto 被推导到 bar
,然后尝试在其上调用 func1()
。如果您的 lambda 没有使用 auto 而是将实际类型作为参数(即 foo
,因此您不能使用 bar
调用它),is_invocable_r_v
将 return false 并且 SFINAE 可以工作。
问题
我写了一段复杂的模板代码,可以编译with GCC 8.2.1, but not with Clang 7.0(代码和错误链接)。
我认为这可能是 this Q&A 的暗示,但我看不到它。
动机
我正在写一个 class,我希望它可以用两个不同类型的可调用对象构造,但也可以省略其中一个,即:
my_class(callable_1);
my_class(callable_2);
my_class(callable_1, callable_2);
那应该没有问题。但是,为什么不允许 callable_1
和 callable_2
成为函数模板(或带有 operator()
模板的函子)。也就是说,我想要这个(或者至少最初想要):
my_class([](auto arg) {});
my_class([](auto arg) {});
my_class([](auto arg) {}, [](auto arg) {});
如您所见,不幸的是,这两个可调用对象具有相同的签名,因此我们需要以某种方式消除它们之间的歧义。我能想到的第一种方法(也是这个问题所涉及的方法)是向其中一个一元重载添加一个 "tag" 参数:
my_class([](auto arg) {});
my_class([](auto arg) {}, callable_2_tag());
my_class([](auto arg) {}, [](auto arg) {});
对我来说,这看起来可以接受,但我想出了更好的解决方案:
- 在第二个可调用对象的签名(最后一个参数或 return 类型)中使用标签(如果不明确则可选)
- 使第二个构造函数重载为不同名称的非成员函数或
static
成员函数
不过,我还是想知道为什么使用我的初始方法的两个编译器在行为上存在差异,哪个是正确的(或者两者是否正确)。
代码:
为简单起见,我已将构造函数重载转换为常规 my_class
函数重载。
#include <iostream>
#include <type_traits>
// parameter types for callbacks and the tag class
struct foo { void func1() {} };
struct bar { void func2() {} };
struct bar_tag {};
// callable checks
template <typename Func>
static constexpr bool is_valid_func_1_v = std::is_invocable_r_v<void, Func, foo>;
template <typename Func>
static constexpr bool is_valid_func_2_v = std::is_invocable_r_v<void, Func, bar>;
// default values
static constexpr auto default_func_1 = [](foo) {};
static constexpr auto default_func_2 = [](bar) {};
// accepting callable 1
template <typename Func1, std::enable_if_t<is_valid_func_1_v<Func1>>* = nullptr>
void my_class(Func1&& func_1)
{
my_class(std::forward<Func1>(func_1), default_func_2);
}
// accepting callable 1
template <typename Func2, std::enable_if_t<is_valid_func_2_v<Func2>>* = nullptr>
void my_class(Func2&& func_2, bar_tag)
{
my_class(default_func_1, std::forward<Func2>(func_2));
}
// accepting both
template <
typename Func1, typename Func2,
// disallow Func2 to be deduced as bar_tag
// (not even sure why this check did not work in conjunction with others,
// even with GCC)
std::enable_if_t<!std::is_same_v<Func2, bar_tag>>* = nullptr,
std::enable_if_t<is_valid_func_1_v<Func1> &&
is_valid_func_2_v<Func2>>* = nullptr>
void my_class(Func1&& func_1, Func2&& func_2)
{
std::forward<Func1>(func_1)(foo());
std::forward<Func2>(func_2)(bar());
}
int main()
{
my_class([](auto foo) { foo.func1(); });
my_class([](auto bar) { bar.func2(); }, bar_tag());
}
对于 Clang,这将导致:
error: no member named 'func1' in 'bar'
my_class([](auto foo) { foo.func1(); });
~~~ ^
...
note: in instantiation of variable template specialization
'is_valid_func_2_v<(lambda at prog.cc:41:14)>' requested here
template <typename Func2, std::enable_if_t<is_valid_func_2_v<Func2>>* = nullptr>
^
这里发生了什么? 替换失败是错误吗?
编辑: 我完全无知地认为 std::enable_if
的谓词中的错误也会被沉默...那就是 不是替换失败。
修复:
如果我将 SFINAE 作为函数参数,Clang 可以很好地处理它。 我不知道为什么将检查从模板参数推导阶段推迟到重载解析阶段会有所不同。
template <typename Func2>
void my_class(Func2&& func_2, bar_tag,
std::enable_if_t<is_valid_func_2_v<Func2>>* = nullptr)
{
my_class(default_func_1, std::forward<Func2>(func_2));
}
总而言之,我对通用性的投入可能超出了我的知识范围,现在我正在为此付出代价。那我错过了什么?细心的 reader 可能会注意到突然出现的一些附带问题,但我不想回答所有这些问题。最后,如果可以制作更简单的 MCVE,我很抱歉。
根据我的理解,您没有完全正确地使用 SFINAE - 如果您尝试使用 Func == decltype([](auto foo) { foo.func1(); }
调用 std::is_invocable_r_v<void, Func, bar>;
,您将遇到编译器错误,因为 lambda 中的 auto 被推导到 bar
,然后尝试在其上调用 func1()
。如果您的 lambda 没有使用 auto 而是将实际类型作为参数(即 foo
,因此您不能使用 bar
调用它),is_invocable_r_v
将 return false 并且 SFINAE 可以工作。