Re: Moving elements out of an initializer-list
On 16 Sep., 16:59, Johannes Schaub wrote:
I think this either shows
- A problem with the wording of initializer_list creation (the
backing-up array is non-const but is inteded to be const?)
I *do* think it's intended to be const. Section 8.5.4 paragraph 5
specifically allows a compiler to allocate/initialize these objects
statically like string literals (if possible). So, casting away
constness and modifying the objects is a bad idea.
- Missing wording that you are not allowed to modify the backing
array of an initializer_list (effectively forbidding moving
things out of it)
- Something we can apply to Standard containers to make them more
widely usable with initializer lists.
- A poorly designed initializer_list interface: Why are you allowed
to move things out, but you would need an explicit cast?
What makes you think you are allowed to do that? Just because
paragraph 4 contains the following example?
" struct X {
X(std::initializer_list<double> v);
};
X x{ 1,2,3 };
The initialization will be implemented in a way roughly
equivalent to
double __a[3] = {double{1},double{2},double{3}};
X x (std::initializer_list<double>(__a,__a+3));
assuming the implementation can construct an initializer_list
with a pair of pointers. "
I don't think this proves that moving is allowed, especially because
this is just an explanation for an example with the wording "roughly
equivalent" in it.
This is my personal opinion, of course. Please let me hear what you think
about it.
To be honest, I don't like std::initializer_list. In my opinion, it's
primarily for toy examples. "Look, Ma! This is how I can initialize my
vector!" In practice, one usually doesn't fill standard containers
like this. Data comes from user input, files, data bases, network
connections, etc. And for simple lookup tables we can still use
statically initialized C arrays. std::initializer_list also doesn't
play nice with move semantics. This is because std::initializer_list
has reference semantics (it doesn't really own its elements) and also
because the draft specifically allows the compiler to use read-only
memory for the elements if it sees fit. No guarantees are made as to
when the elements really have automatic storage and when not.
Victor Bazarov wrote:
Each element of that array is copy-initialized with the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
corresponding element of the initializer list, .. "
I don't think that "copy-initialization" rules out move construction.
But I admit that this term is confusing.
Cheers!
SG