Initializer-list-constructing a vector of noncopyable (but movable) objects

Question

One can push_back rvalues of a noncopyable-but-movable type into a vector of that type:

#include <vector>

struct S
{
    S(int);
    S(S&&);
};

int main()
{
    std::vector<S> v;
    v.push_back(S(1));
    v.push_back(S(2));
    v.push_back(S(3));
}

However, when I try to initializer-list-construct the vector with the same rvalues, I get errors about a copy constructor being required:

#include <vector>

struct S
{
    S(int);
    S(S&&);
};

int main()
{
    std::vector<S> v = {S(1), S(2), S(3)};
}

I get the following errors with GCC 4.7:

In file included from include/c++/4.7.0/vector:63:0,
                 from test.cpp:1:
include/c++/4.7.0/bits/stl_construct.h: In instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = S, _Args = {const S&}]':
include/c++/4.7.0/bits/stl_uninitialized.h:77:3:   required from 'static _ForwardIterator std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = const S*, _ForwardIterator = S*, bool _TrivialValueTypes = false]'
include/c++/4.7.0/bits/stl_uninitialized.h:119:41:   required from '_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = const S*, _ForwardIterator = S*]'
include/c++/4.7.0/bits/stl_uninitialized.h:260:63:   required from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator = const S*, _ForwardIterator = S*, _Tp = S]'
include/c++/4.7.0/bits/stl_vector.h:1185:4:   required from 'void std::vector<_Tp, _Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with _ForwardIterator = const S*, _Tp = S, _Alloc = std::allocator<S>]'
include/c++/4.7.0/bits/stl_vector.h:362:2:   required from 'std::vector<_Tp, _Alloc>::vector(std::initializer_list<_Tp>, const allocator_type&) [with _Tp = S, _Alloc = std::allocator<S>, std::vector<_Tp, _Alloc>::allocator_type = std::allocator<S>]'
test.cpp:11:41:   required from here
include/c++/4.7.0/bits/stl_construct.h:77:7: error: no matching function for call to 'S::S(const S&)'
include/c++/4.7.0/bits/stl_construct.h:77:7: note: candidates are:
test.cpp:6:5: note: S::S(S&&)
test.cpp:6:5: note:   no known conversion for argument 1 from 'const S' to 'S&&'
test.cpp:5:5: note: S::S(int)
test.cpp:5:5: note:   no known conversion for argument 1 from 'const S' to 'int'

Should this be allowed? I see no technical obstacles to it being allowed, but I don't have the Standard handy at the moment...

Oria

It looks like the only way to fill a vector with moveable objects is to revert to the old style: std::vector<S> v; v.emplace_back(S(1)); v.emplace_back(S(2)); v.emplace_back(S(3));` (or shorter/obcure v.emplace_back(1); etc ...). Sad, isn't it? – Assoil

You can use push_back if the template type is MoveInsertable. – Dives

@JensÅkerblom: I'm aware; in fact, that's what my first code snippet shows. Sometimes, though, you want to use an inline syntax. – Oria

Similar question: #8469274 – Vinaigrette

Answer 1

Maybe this clause from 8.5.4.5 explains it (my emphasis):

An object of type std::initializer_list is constructed from an initializer list as if the implementation allocated an array of N elements of type E, where N is the number of elements in the initializer list. Each element of that array is copy-initialized with the corresponding element of the initializer list, and the std::initializer_list object is constructed to refer to that array.

So you can only initialize from lists if the objects are copyable.

---

Update: As Johannes points out, copy-initialization can be realized by both copy and move constructors, so that alone isn't enough to answer the question. Here is, however, an excerpt of the specification of the initializer_list class as described in 18.9:

  template<class _E>
    class initializer_list
    {
    public:
      typedef _E            value_type;
      typedef const _E&     reference;
      typedef const _E&     const_reference;
      typedef size_t        size_type;
      typedef const _E*     iterator;
      typedef const _E*     const_iterator;

Note how there are no non-constant typedefs!

I just tried making an IL constructor which would traverse the initializer list via std::make_move_iterator, which failed because const T & cannot be converted to T&&.

So the answer is: You cannot move from the IL, because the standard says so.

Scanties

@sehe: it's a quote from the N3290 FDIS. I assume it's normative! :-) – Scanties

I see. This seems to be a missed optimization opportunity in the standard, then... perhaps it will be fixed in the next version :) – Oria

This answer confuses more than it helps. Copy-initializing does not mean to "only copy but not move". Copy-initializing may well involved moving. It just means that you initialize as-if you had done T t = e;. e can be some rvalue moved into t. – Panto

@Johannes: I never said otherwise - I didn't say which sort of construction is invoked consequent to the copy-initialization. Do you have a suggestion for improvement? – Scanties

@Johannes: So why does the moving not work, then? Is it just the libstdc++ implementation, or is there something else in the standard that forbids it? – Oria

I updated the answer to contain the real reason you cannot move! – Scanties

Answer 2

It appears it might be a compiler issue. This works in g++ 4.5.1 (click for IdeOne online demo)

Conclusion: It was, in the sense that older g++ implementations did not correctly flag an error; initializer lists do not support moving their elements (elements are implicitely copied in the process). Thank to Kerrek SB for quoting the helpful phrase from the standard.

---

Old proceedings (for the sake of understanding the comments:)

_{Edit Found out that at least g++ 4.6.1+ seem to have your complaint about this code.}

Edit Upon reading the source to std::initializer_list<T> I'm starting to get the impression that this is not supported by the library (it looks intentional). Whether the standard actually allows for an initializer list to forward the xvalue-ness of it's elements... I wouldn't be surprised if they stopped there (perfect forwarding is still not easily supported in C++0x I think, and not all initializer parameters would need to have the same (deductable) type.

Anyone with more standardese under his belt care to help out? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2640.pdf

#include <vector>

struct S
{
    S(int) {};
    S(S&&) {};
};

int main()
{
    std::vector<S> v = {S(1), S(2), S(3)};
    std::vector<S> w = {std::move(S(1)), std::move(S(2)), std::move(S(3))};

    std::vector<S> or_even_just = {1, 2, 3};
}

Mckeever

This does not help at all (I get the same errors), and that's not surprising - all std::move does is turn an lvalue into an rvalue. Since S(1), S(2), and S(3) are already rvalues, wrapping them in std::move accomplishes absolutely nothing. – Oria

@HighCommander4: no, std::move turns them into rvalue references. Not the same thing. Let me check things locally. Meanwhile, head over here for some helpful hints/explanations – Mckeever

Pretty sure this is a compiler issue: ideone.com/bYhq9 shows it works just fine with g++ 4.5.1, with or without std::move. I suggest using implicit construction b.t.w. – Mckeever

That would be because GCC 4.5 doesn't implement the automatic generation of move/copy constructors correctly - it (incorrectly) generates a copy constructor for S even though a user-defined move constructor is present, and then uses it to copy the initializer-list objects. Add a private copy constructor to S, and you will see GCC 4.5 gives the same error now. – Oria

Have edited answer with findings. Thanks everyone for correcting; I've learned a thing or two about the compiler I'm using everyday – Mckeever

Answer 3

The initializer_list only provides const references and const iterators. There is no way for the vector to move from that.

template<class E> 
class initializer_list {
public:
    typedef E value_type;

    typedef const E& reference;
    typedef const E& const_reference;

    typedef size_t size_type;

    typedef const E* iterator;
    typedef const E* const_iterator;

Rheum

The language currently doesn't forbid to cast away the const and then move from the objects. But I consider that a language defect. – Panto

Answer 4

It seems the answer is No per Kerrek SB's answer. But you can achieve something similar by small helper functions using variadic templates:

#include <vector>
#include <utility>

template <typename T>
void add_to_vector(std::vector<T>* vec) {}

template <typename T, typename... Args>
void add_to_vector(std::vector<T>* vec, T&& car, Args&&... cdr) {
  vec->push_back(std::forward<T>(car));
  add_to_vector(vec, std::forward<Args>(cdr)...);
}

template <typename T, typename... Args>
std::vector<T> make_vector(Args&&... args) {
  std::vector<T> result;
  add_to_vector(&result, std::forward<Args>(args)...);
  return result;
}

struct S {
  S(int) {}
  S(S&&) {}
};

int main() {
  std::vector<S> v = make_vector<S>(S(1), S(2), S(3));
  return 0;
}

Penmanship