2017-01-10 96 views
3

我的问题是关于std::initializer_list类型之间缺少转换,其中包含的类型或多或少具有cv限定的转换似乎很容易实现。std :: initializer_list <int const>不能从std :: initializer_list构建<int>

考虑下面的代码是无效的:

std::initializer_list<int> x{1,2,3,4,5,6}; 
std::initializer_list<int const> y = x; // error! cannot convert! 

现在考虑std::optional而忽略了可笑的类型:

std::optional<std::vector<int>> x{std::in_place, {1,2,3,4,5}}; // OK 
std::optional<std::vector<int const>> y{std::in_place, {1,2,3,4,5}}; // error! 

承担语言规范要求推导非CV合格U的对于std::initializer_list<U>默认情况下。

据我所知,具有std::initializer_list构造函数重载std::optional(和std::anystd::variant)整点是避免指定初始化列表的确切类型。要获得上面代码的第二行来编译,那正是你必须做的。

std::initializer_list已经拥有一个const*它的数据(无论如何在libc++)。我没有理由看到上面的代码不工作?这是一个可以解决的问题,或者我错过了什么?

+3

这是一种很难“忽略可笑的类型”,当'矢量'在C++中明确*不合法*。那么为什么你会期望'initializer_list '工作?你会用它初始化什么? –

+0

说实话,我不知道。当我发现这一点时,我正在编写一个通用的包装类型。 – xcvr

+0

也许这对于一些类似于“dynarray”的类型是有意义的。 – xcvr

回答

3

听起来像你的问题是为什么std::initializer_list<T const>不能从std::initializer_list<T>构造,尽管事实上它很容易实现这样的转换。

我认为答案是,你不应该有std::initializer_list<T const>首先,因为,正如你所指出的,std::initializer_list<T>只能给const访问它的元素无论如何。

因此可以说C++中存在一个“文化规范”,你不应该有任何需要std::initializer_list<T const>参数的构造函数。例如,没有一个标准库容器可以做,因为无论如何cv限定的值类型都是非法的(除非是std::array,当然,它无论如何都没有用户定义的构造函数)。

如果你写你自己的类型MyContainer支持MyContainer<T const>,那么我建议你使它看起来像下面这样:

template <class T> 
class MyContainer { 
    public: 
    MyContainer(std::initializer_list<std::remove_cv_t<T>> il); 
    // ... 
}; 
+0

“文化规范”似乎是正确的!如果某人(你?)可以解释为什么如果所有初始化器列表与“std :: initializer_list ”具有相同的语义,那么为什么我不会推断这是为了'std :: initializer_list '。 – xcvr

+1

@xcvr,因为'std :: initializer_list'的模板参数是使用模板参数推导的通常规则推导出来的,它不会推导出cv限定类型,引用类型,数组类型或函数类型。 – Brian

+0

虽然我认为通常的模板参数推导规则在窗口不能被推断出来的时候,除非它被指定为'std :: initializer_list '。 – xcvr

相关问题