g++ 不采用可变参数推导指南,clang++ 采用-谁是正确的? [英] Variadic deduction guide not taken by g++, taken by clang++ - who is correct?

查看:30
本文介绍了g++ 不采用可变参数推导指南,clang++ 采用-谁是正确的?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

考虑以下代码:

template <typename... Types>
struct list
{
    template <typename... Args>
    list(Args...) 
    {
        static_assert(sizeof...(Types) > 0);
    }
};

template <typename... Args>
list(Args...) -> list<Args...>;

int main()
{
    list l{0, 0.1, 'a'};
}

我希望 decltype(l)list.不幸的是,g++ 7.2g++ trunk 未能通过静态断言.clang++ 5.0.0clang++ trunk 编译并按预期工作.

I would expect decltype(l) to be list<int, double, char>. Unfortunately, g++ 7.2 and g++ trunk fail the static assertion. clang++ 5.0.0 and clang++ trunk compile and work as expected.

godbolt.org 一致性视图

这是一个 g++ 错误吗?或者有什么理由不应该在这里遵循演绎指南?

Is this a g++ bug? Or Is there a reason why the deduction guide should not be followed here?

在构造函数上添加 SFINAE 约束似乎提供了所需的行为:

Adding a SFINAE constraint on the constructor seems to provide the desired behavior:

template <typename... Args, 
          typename = std::enable_if_t<sizeof...(Args) == sizeof...(Types)>>
list(Args...) 
{
    static_assert(sizeof...(Types) > 0);
}

godbolt.org 一致性视图

推荐答案

这是 gcc 错误 80871.问题是,我们最终得到了这组推演的候选对象:

This is gcc bug 80871. The issue is, we end up with this set of candidates for deduction:

template <class... Types, class... Args>
list<Types...> __f(Args... ); // constructor

template <class... Args>
list<Args...>  __f(Args... ); // deduction-guide

两者都是有效的(Types... 在第一种情况下可以推断为空),但是这里的调用应该是模棱两可的 - 两者都不比另一个更专业.Types... 不参与这里的排序(类似于 [temp.deduct.partial]/12).所以正确的行为是继续下一个决胜局,它赞成演绎指南.因此,这应该是一个 list.

Both are valid (Types... can deduce as empty in the first case), but the call here should be ambiguous - neither is more specialized than the other. Types... does not participate in ordering here (similar to the example in [temp.deduct.partial]/12). So the correct behavior is to proceed to the next tiebreaker, which favors deduction-guides. Hence, this should be a list<int, double, char>.

然而,gcc 的行为是有利于构造函数,因此 static_assert 触发器因为 Types... 在这种情况下确实是空的.

However, gcc's behavior is to favor the constructor, hence the static_assert triggers becuase Types... would indeed be empty in that situation.

这篇关于g++ 不采用可变参数推导指南,clang++ 采用-谁是正确的?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆