initializer_list and move semantics
Solution 1
No, that won't work as intended; you will still get copies. I'm pretty surprised by this, as I'd thought that initializer_list
existed to keep an array of temporaries until they were move
'd.
begin
and end
for initializer_list
return const T *
, so the result of move
in your code is T const &&
— an immutable rvalue reference. Such an expression can't meaningfully be moved from. It will bind to an function parameter of type T const &
because rvalues do bind to const lvalue references, and you will still see copy semantics.
Probably the reason for this is so the compiler can elect to make the initializer_list
a statically-initialized constant, but it seems it would be cleaner to make its type initializer_list
or const initializer_list
at the compiler's discretion, so the user doesn't know whether to expect a const
or mutable result from begin
and end
. But that's just my gut feeling, probably there's a good reason I'm wrong.
Update: I've written an ISO proposal for initializer_list
support of move-only types. It's only a first draft, and it's not implemented anywhere yet, but you can see it for more analysis of the problem.
Solution 2
bar(std::move(*it)); // kosher?
Not in the way that you intend. You cannot move a const
object. And std::initializer_list
only provides const
access to its elements. So the type of it
is const T *
.
Your attempt to call std::move(*it)
will only result in an l-value. IE: a copy.
std::initializer_list
references static memory. That's what the class is for. You cannot move from static memory, because movement implies changing it. You can only copy from it.
Solution 3
This won't work as stated, because list.begin()
has type const T *
, and there is no way you can move from a constant object. The language designers probably made that so in order to allow initializer lists to contain for instance string constants, from which it would be inappropriate to move.
However, if you are in a situation where you know that the initializer list contains rvalue expressions (or you want to force the user to write those) then there is a trick that will make it work (I was inspired by the answer by Sumant for this, but the solution is way simpler than that one). You need the elements stored in the initialiser list to be not T
values, but values that encapsulate T&&
. Then even if those values themselves are const
qualified, they can still retrieve a modifiable rvalue.
template<typename T>
class rref_capture
{
T* ptr;
public:
rref_capture(T&& x) : ptr(&x) {}
operator T&& () const { return std::move(*ptr); } // restitute rvalue ref
};
Now instead of declaring an initializer_list<T>
argument, you declare aninitializer_list<rref_capture<T> >
argument. Here is a concrete example, involving a vector of std::unique_ptr<int>
smart pointers, for which only move semantics is defined (so these objects themselves can never be stored in an initializer list); yet the initializer list below compiles without problem.
#include <memory>
#include <initializer_list>
class uptr_vec
{
typedef std::unique_ptr<int> uptr; // move only type
std::vector<uptr> data;
public:
uptr_vec(uptr_vec&& v) : data(std::move(v.data)) {}
uptr_vec(std::initializer_list<rref_capture<uptr> > l)
: data(l.begin(),l.end())
{}
uptr_vec& operator=(const uptr_vec&) = delete;
int operator[] (size_t index) const { return *data[index]; }
};
int main()
{
std::unique_ptr<int> a(new int(3)), b(new int(1)),c(new int(4));
uptr_vec v { std::move(a), std::move(b), std::move(c) };
std::cout << v[0] << "," << v[1] << "," << v[2] << std::endl;
}
One question does need an answer: if the elements of the initializer list should be true prvalues (in the example they are xvalues), does the language ensure that the lifetime of the corresponding temporaries extends to the point where they are used? Frankly, I don't think the relevant section 8.5 of the standard addresses this issue at all. However, reading 1.9:10, it would seem that the relevant full-expression in all cases encompasses the use of the initializer list, so I think there is no danger of dangling rvalue references.
Solution 4
I thought it might be instructive to offer a reasonable starting point for a workaround.
Comments inline.
#include <memory>
#include <vector>
#include <array>
#include <type_traits>
#include <algorithm>
#include <iterator>
template<class Array> struct maker;
// a maker which makes a std::vector
template<class T, class A>
struct maker<std::vector<T, A>>
{
using result_type = std::vector<T, A>;
template<class...Ts>
auto operator()(Ts&&...ts) const -> result_type
{
result_type result;
result.reserve(sizeof...(Ts));
using expand = int[];
void(expand {
0,
(result.push_back(std::forward<Ts>(ts)),0)...
});
return result;
}
};
// a maker which makes std::array
template<class T, std::size_t N>
struct maker<std::array<T, N>>
{
using result_type = std::array<T, N>;
template<class...Ts>
auto operator()(Ts&&...ts) const
{
return result_type { std::forward<Ts>(ts)... };
}
};
//
// delegation function which selects the correct maker
//
template<class Array, class...Ts>
auto make(Ts&&...ts)
{
auto m = maker<Array>();
return m(std::forward<Ts>(ts)...);
}
// vectors and arrays of non-copyable types
using vt = std::vector<std::unique_ptr<int>>;
using at = std::array<std::unique_ptr<int>,2>;
int main(){
// build an array, using make<> for consistency
auto a = make<at>(std::make_unique<int>(10), std::make_unique<int>(20));
// build a vector, using make<> because an initializer_list requires a copyable type
auto v = make<vt>(std::make_unique<int>(10), std::make_unique<int>(20));
}
Solution 5
Instead of using a std::initializer_list<T>
, you can declare your argument as an array rvalue reference:
template <typename T>
void bar(T &&value);
template <typename T, size_t N>
void foo(T (&&list)[N] ) {
std::for_each(std::make_move_iterator(std::begin(list)),
std::make_move_iterator(std::end(list)),
&bar);
}
void baz() {
foo({std::make_unique<int>(0), std::make_unique<int>(1)});
}
See example using std::unique_ptr<int>
: https://gcc.godbolt.org/z/2uNxv6
Related videos on Youtube
Comments
-
fredoverflow almost 4 years
Am I allowed to move elements out of a
std::initializer_list<T>
?#include <initializer_list> #include <utility> template<typename T> void foo(std::initializer_list<T> list) { for (auto it = list.begin(); it != list.end(); ++it) { bar(std::move(*it)); // kosher? } }
Since
std::intializer_list<T>
requires special compiler attention and does not have value semantics like normal containers of the C++ standard library, I'd rather be safe than sorry and ask.-
Johannes Schaub - litb over 12 yearsThe core language defines that the object referred to by an
initializer_list<T>
are non-const. Like,initializer_list<int>
refers toint
objects. But I think that is a defect - it is intended that compilers can statically allocate a list in read only memory.
-
-
Luc Danton over 12 yearsIn case it isn't clear, it still means using
std::move
is safe, if not productive. (BarringT const&&
move constructors.) -
David Rodríguez - dribeas over 12 yearsI don't think that you could make the whole argument either
const std::initializer_list<T>
or juststd::initializer_list<T>
in a way that does not cause surprises quite often. Consider that each argument in theinitializer_list
can be eitherconst
or not and that is known in the context of the caller, but the compiler must generate just one version of the code in the context of the callee (i.e. insidefoo
it does not know anything about the arguments that the caller is passing in) -
Potatoswatter over 12 years@David: Good point, but it would still be useful to have a
std::initializer_list &&
overload do something, even if a non-reference overload is also required. I suppose it would be even more confusing than the current situation, which is already bad. -
Potatoswatter over 12 yearsA const xvalue is still an xvalue, and
initializer_list
references the stack if that is necessary. (If the contents are not constant, it is still thread-safe.) -
Nicol Bolas over 12 years@Potatoswatter: You cannot move from a constant object. The
initializer_list
object itself may be an xvalue, but it's contents (the actual array of values that it points to) areconst
, because those contents may be static values. You simply cannot move from the contents of aninitializer_list
. -
Potatoswatter over 12 yearsSee my answer and its discussion. He has moved the dereferenced iterator, producing a
const
xvalue.move
might be meaningless, but it's legal and even possible to declare a parameter that accepts just that. If moving a particular type happens to be a no-op, it might even work correctly. -
Nicol Bolas over 12 years@Potatoswatter: The C++11 standard expends a lot of language ensuring that non-temporary objects are not actually moved unless you use
std::move
. This ensures that you can tell from inspection when a move operation happens, since it affects both the source and the destination (you don't want it to happen implicitly for named objects). Because of that, if you usestd::move
in a place where a move operation doesn't happen (and no actual movement will happen if you have aconst
xvalue), then the code is misleading. I think it's a mistake forstd::move
to be callable on aconst
object. -
Potatoswatter over 12 yearsMaybe, but I'll still take fewer exceptions to the rules over the possibility of misleading code. Anyway, that is exactly why I answered "no" even though it's legal, and the result is an xvalue even if it will only bind as a const lvalue. To be honest, I've already had a brief flirtation with
const &&
in a garbage-collected class with managed pointers, where everything relevant was mutable and moving moved the pointer management but didn't affect the contained value. There are always tricky edge cases :v) . -
fredoverflow over 10 yearsWhy on earth would you want to determine the value category at runtime when the compiler already knows it?
-
Sumant over 10 yearsPlease read the blog and leave me a comment if you disagree or have a better alternative. Even if the compiler knows the value category, initializer_list does not preserve it because it has only const iterators. So you need to "capture" the value category when you construct the initializer_list and pass it through so the function can make use of it as it pleases.
-
Jean-Bernard Jansen about 10 yearsYou may be interested by this article: cpptruths.blogspot.fr/2013/10/…
-
Potatoswatter about 10 years@JBJansen It can't be hacked around. I don't see exactly what that code is supposed to accomplish wrt initializer_list, but as the user you do not have the needed permissions to move from it. Safe code will not do so.
-
Jean-Bernard Jansen about 10 yearsYes you can hack it with mutable values used correctly. Such haking may be dangerous as forward_as_tuple is if not used correctly. May be you will be interested in this: stackoverflow.com/questions/13957166/…
-
dyp almost 10 yearsString constants? Like
"Hello world"
? If you move from them, you just copy a pointer (or bind a reference). -
dyp almost 10 years"One question does need an answer" The initializers inside
{..}
are bound to references in the function parameter ofrref_capture
. This does not extend their lifetime, they're still destroyed at the end of the full-expression in which they've been created. -
Yakk - Adam Nevraumont almost 8 yearsThis answer is basically useless without following the link, and SO answers should be useful without following links.
-
underscore_d over 7 years@Sumant [copying my comment from an identical post elsewhere] Does that humungous mess actually provide any measurable benefits to performance or memory usage, and if so, a sufficiently large amount of such benefits to adequately offset how terrible it looks and the fact that it takes about an hour to figure out what it's trying to do? I kinda doubt it.
-
Kuba hasn't forgotten Monica over 7 yearsPer T.C.'s comment from another answer: If you have multiple overloads of the constructor, wrap the
std::initializer_list<rref_capture<T>>
in some transformation trait of your choosing - say,std::decay_t
- to block unwanted deduction. -
underscore_d almost 7 yearsThe question was if an
initializer_list
can be moved from, not whether anyone had workarounds. Besides, the main selling point ofinitializer_list
is that it is only templated on the element type, not the number of elements, and therefore does not require recipients to also be templated - and this completely loses that. -
underscore_d almost 7 yearsThe question was if an
initializer_list
can be moved from, not whether anyone had workarounds. Besides, the main selling point ofinitializer_list
is that it is only templated on the element type, not the number of elements, and therefore does not require recipients to also be templated - and this completely loses that. -
Richard Hodges almost 7 years@underscore_d you're absolutely right. I take the view that sharing knowledge related to the question is a good thing in itself. In this case, perhaps it helped the OP and perhaps it didn't - he didn't respond. More often than not however, the OP and others welcome extra material related to the question.
-
underscore_d almost 7 yearsSure, it may indeed help for readers who want something like
initializer_list
but aren't subject to all the constraints that make it useful. :) -
Richard Hodges almost 7 years@underscore_d which of the constraints have I overlooked?
-
underscore_d almost 7 yearsAll I mean is that
initializer_list
(via compiler magic) avoids having to template functions on the number of elements, something that is inherently required by alternatives based on arrays and/or variadic functions, thus constraining the range of cases where the latter are usable. By my understanding, this is precisely one of the main rationales for havinginitializer_list
, so it seemed worth mentioning. -
WhiZTiM almost 7 years@Potatoswatter, late comment, but what's the status of the proposal. Is there any remote chance it may make it into C++20?
-
Potatoswatter almost 7 years@WhiZTiM I'm not so active in C++ lately (ISO or otherwise), but anything is possible. It's an open standard — if you want, you can promote the idea yourself! C++20 should certainly still be open to new ideas, since C++17 is yet to be ratified.
-
Michaël about 3 yearsHas this proposal made any progress? I'm also fairly surprised that initializer lists force copies.
-
Smiley1000 over 2 yearsI've switched to using
std::array<T, N>&&
instead ofstd::initializer_list<T>
in my code. -
John about 2 years@Potatoswatter Though begin() and end() for initializer_list return const T *. Since the code is written as auto it = list.begin(),
it
is notconst
indeed, so I think bar(std::move(*it)); should be compiled. Where am I wrong? I am really confused now. Thanks a lot. -
John about 2 years@NicolBolas So the type of it is
const T *
.. Sorry, could you please explain that in more detail for me? Thoughbegin()
andend()
forinitializer_list
returnconst T *
. Since the code is written asauto it = list.begin()
,it
is notconst
indeed, so I thinkbar(std::move(*it));
should be compiled. Where am I wrong? I am really confused now. -
Nicol Bolas about 2 years@John: "Since the code is written as auto it = list.begin(), it is not const indeed" Incorrect.
auto
will deduce whatever the type of the expression is. As pointed out, that type isconst T*
; theconst
is not optional. Therefore, that is whatauto
will deduce. -
John about 2 years@NicolBolas As per stackoverflow.com/a/32131498/13611002, it seems that the deduction for
auto
would ignoreconst
indeed, e.g.:const int const_num=0; const i=const_num;
,i
isint
other thanconst int
. And See this code snippet. -
axerologementy almost 2 yearsSadly this seems to break the A{a, b, c} syntax, requiring A({a, b, c}) instead to work.
-
Elliot almost 2 years@Potatoswatter Can you expand on "ownership is a superset of observation"? I don't think I understand this.