initializer_list et la sémantique de déplacement

Non, ça ne fonctionne pas comme prévu, vous aurez toujours une copie. Je suis assez surpris par cela, comme je l'avais pensé que initializer_list permettaient de tenir un tableau de temporaires jusqu'à ce qu'ils étaient move'd.

begin et end pour initializer_list retour const T *, de sorte que le résultat de move dans votre code est T const && — immuable référence rvalue. Une telle expression ne peut pas véritablement être déplacé d'. Il va se lier à un paramètre de fonction de type T const & parce que rvalues ne se lier à const lvalue références, et vous verrez toujours la sémantique de copie.

Probablement la raison pour cela est que le compilateur peut choisir d'effectuer le initializer_list une manière statique initialisé constante, mais il semble qu'il serait plus propre de faire son type initializer_list ou const initializer_list au compilateur de la discrétion, de sorte que l'utilisateur ne sait pas s'attendre à une const ou mutable résultat de begin et end. Mais c'est juste mon sentiment, il y a probablement une bonne raison je me suis trompé.

Mise à jour: j'ai écrit une proposition de l'ISO pour initializer_list soutien de déplacer uniquement les types. C'est seulement une première ébauche, et il n'est pas mis en œuvre partout, mais vous pouvez le voir, pour une analyse plus approfondie du problème.

Cela ne fonctionne pas comme indiqué, parce que list.begin() a type const T *, et il n'y a aucun moyen que vous pouvez déplacer à partir d'un objet constant. La langue concepteurs probablement fait que c'est dans le but de permettre à l'initialiseur listes contiennent par exemple des constantes de chaîne, à partir de laquelle il serait inapproprié de se déplacer.

Toutefois, si vous êtes dans une situation où vous savez que l'initialiseur liste contient rvalue expressions (ou si vous voulez forcer l'utilisateur à écrire ces) puis il y a un truc qui va faire fonctionner (j'ai été inspiré par la réponse par Sumant pour cela, mais la solution est plus simple que ça). Vous avez besoin des éléments stockés dans les initialiser la liste pour ne pas être T valeurs, mais les valeurs qui encapsulent T&&. Alors, même si ces valeurs elles-mêmes sont const qualifiés, ils peuvent toujours récupérer 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
};

Maintenant, au lieu de déclarer une initializer_list<T> argument, vous déclarez uninitializer_list<rref_capture<T> > argument. Voici un exemple concret, impliquant un vecteur de std::unique_ptr<int> pointeurs intelligents, pour qui seule la sémantique de déplacement est défini (de sorte que ces objets eux-mêmes ne peuvent jamais être stockés dans une liste d'initialiseur); cependant, l'initialiseur de la liste ci-dessous compile sans problème.

#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;
}

Une question nécessite une réponse: si les éléments de la liste d'initialiseur doit être vrai prvalues (dans l'exemple, ils sont xvalues), la langue s'assurer que la durée de vie de l'correspondant temporaires s'étend jusqu'au point où ils sont utilisés? Franchement, je ne pense pas que la section correspondante de l'article 8.5 de la norme traite de cette question. Cependant, la lecture de 1.9:10, il semblerait que la pleine expression dans tous les cas, englobe l'utilisation de la liste d'initialiseur, donc je pense qu'il n'y a pas de danger, en balançant les références rvalue.

Il ne semble pas autorisés dans la norme actuelle comme déjà répondu. Voici une autre solution pour obtenir quelque chose de similaire, par définition de la fonction comme variadic au lieu de prendre un initialiseur de liste.

#include <vector>
#include <utility>
//begin helper functions
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;
}
//end helper functions
struct S {
S(int) {}
S(S&&) {}
};
void bar(S&& s) {}
template <typename T, typename... Args>
void foo(Args&&... args) {
std::vector<T> args_vec = make_vector<T>(std::forward<Args>(args)...);
for (auto& arg : args_vec) {
bar(std::move(arg));
}
}
int main() {
foo<S>(S(1), S(2), S(3));
return 0;
}

Variadic templates peut gérer la r-valeur de références de manière appropriée, à la différence de initializer_list.

Dans cet exemple de code, j'ai utilisé un ensemble de petites fonctions d'aide à convertir les variadic arguments dans un vecteur, pour la rendre semblable à l'original du code. Mais bien sûr, vous pouvez écrire une fonction récursive avec variadic templates directement à la place.