variant<string> v("abc"); // OK
variant<string,string> w("abc"); // ill-formed,can't select the alternative to convert to
variant<string,bool> w("abc"); // OK,but chooses bool
有没有必要的情况呢？
另一个问题是为什么需要同一个cpp参考页面中的构造函数(6)和(8). (5)和(7)是否符合(6)和(8)的目的？我可能会误会他们的用法
对于读者,我在问题中提到的构造函数是
constexpr variant(); // (1) (since C++17) variant(const variant& other); // (2) (since C++17) variant(variant&& other); // (3) (since C++17) template< class T > // (4) (since C++17) constexpr variant(T&& t); template< class T,class... Args > constexpr explicit variant(std::in_place_type_t<T>,Args&&... args); // (5) (since C++17) template< class T,class U,std::initializer_list<U> il,Args&&... args); // (6) (since C++17) template< std::size_t I,class... Args > constexpr explicit variant(std::in_place_index_t<I>,Args&&... args) // (7) (since C++17) template <size_t I,class... Args> constexpr explicit variant(std::in_place_index_t<I>,Args&&... args); // (8) (since C++17)
解决方法
Is there some case where it is absolutely going to be needed?
不,但事情并没有被添加,因为它们是“绝对需要的”.它们被添加,因为它们是有用的.
并且从其一个组件类型隐式转换对于变体非常有用.是的,在某些角落情况下会造成歧义.但是,这种歧义通常是由于类型设计中的缺陷(如字符串字面意思,倾向于通过用户定义的转换转换为bool).
如果有一个模糊的情况,那么你只需要明确.就像使用“abc”的UDL文字而不是裸线字符串(另一个原因).但是当处理精心设计的类型时,没有任何理由强迫大家明确.
Won’t (5) and (7) serve the purposes that (6) and (8) are meant for?
不合理的方式.
在标准的每种情况下,当一个函数使用将被传递给构造函数的可变参数时,它们将使用构造函数语法而不是该对象上的{}语法.所以如果你有这个：
using type = vector<int>; variant<type> t(in_place<type>,6);
你会得到一个调用矢量< int>(6).请注意,这与矢量< int> {6}不同.也就是说,除非您实际通过初始化程序列表,否则您不会获取初始化列表构造函数.
现在,你可以做：
variant<type> t(in_place<type>,initializer_list<int>{6});
但这太过分了.相比之下：
variant<type> t(in_place<type>,{6});
这不算冗长.编译器可以推导出初始化器列表的类型.而如果您尝试将一个支持的初始化列表推导为任意T,则模板参数类型扣除失败.
除了其他方式,模板扣除与auto的推导不同,因为它不会从braced-init-list表达式中推导出initializer_lists.例如
template <typename Type> void func(const Type&);
不会将类型推定为以下调用的std :: initializer_list
func({1,2,3,4,5});
