[c++0x] Lumière sur les rvalue references

Ce n'est pas un peu redondant ? Car dans la fonction Set de MonAutreObjet, je devrais visiblement appeler de nouveau std::move ?

Code:

---

1 2 3 4

MonAutreObjet::Set(std::vector<unsigned int>&& vec) { monObjet = std::move<std::vector<unsigned int>> (vec_); }

---

Non, ce n'est pas redondant car dans l'autre objet on fait directement :

Code:

---

1 2 3 4

MonAutreObjet::Set(std::vector<unsigned int>&& vec) { vec_ = vec; }

---

Qui appelle l'opérateur de déplacement de std::vector (operator=(std::vector<>&&)) :ccool:

Ou peut-être ça :

Code:

---

1 2 3 4

MonAutreObjet::Set(std::vector<unsigned int>&& vec) { vec_ = std::move(vec); }

---

C'est justement sur ce point là que le standard n'est pas fixé…

Ok merci de vos réponses :).

Ouups pardon, Florian a raison :oops:
J'oublie toujours le deuxième move dans la fonction d'arrivée. Désolé.

Il me semble que l'idée du comité c'était d'éviter à tout prix au programmeur de se tirer une balle dans le pied avec des move "silencieux" du type :

Code:

---

1 2 3 4 5 6

set(vector<int>&& vec) { vec1 = vec; vec2 = vec; // erreur, vec a déjà été déplacé à la ligne au-dessus ! }

---

Alors qu'avec les règles actuelles il faut faire :

Code:

---

1 2 3 4 5 6

set(vector<int>&& vec) { vec1 = std::move(vec); vec2 = std::move(vec); // erreur, mais on l'a un peu cherché :) }

---

Une dernière chose :

Citation:

---

Envoyé par Bakura

et que le && ne servait que pour les valeurs de retours...

---

C'est un piège...
Florian, je pense que dans l'article en cours de rédaction sur les rvalue reference il va falloir écrire un gros disclaimer du genre :

Citation:

---

Si vous vous sentez dans l'obligation d'écrire du code comme celui-ci :

Code:

---

T&& foo() { /*...*/}

---

You're doing it wrong :mrgreen:

---

Renvoyer une rvalue reference est à proscrire dans 99% des cas, exactement comme pour une référence classique et pour la même raison : car on renvoit une référence sur un objet local, qui disparait à la fin de la fonction.

Vu la façon dont je présente la chose, je pense que le lecteur a peu de chances d'arriver à cette idée… enfin j'espère !
Je garde cette remarque sous le coude ;)

Merci bien, vous m'enlevez bien des soucis, j'ai hâte de pouvoir lire en entier ton article Florian (j'ai commencé à le lire mais il est incomplet encore :aie: ).

Citation:

---

Envoyé par Florian Goo

Vu la façon dont je présente la chose, je pense que le lecteur a peu de chances d'arriver à cette idée… enfin j'espère !
Je garde cette remarque sous le coude ;)

---

Qu'ouïe-je? Un article sur les rvalues? Sur dvlp? En voilà une nouvelle qu'elle est bonne.

Citation:

---

Envoyé par Goten

Qu'ouïe-je? Un article sur les rvalues? Sur dvlp? En voilà une nouvelle qu'elle est bonne.

---

Je vais spoiler, il va même avoir DEUX articles sur les R-Value références :ccool:.

Là ça serait même plutôt du teasing, et c'est pas cool du tout pour mes nerfs :p

Pour répondre à la question initiale, je pense que lorsque j'aurais à le faire, j'essaierai de toujours m'arranger pour que le move se trouve en fin de bloc
:

Code:

---

1 2 3 4 5 6 7 8 9

void f() { std::vector v2; { std::vector v; .... v2 = std::move(v); } }

---

Du coup, c'est quasiment auto-commenté, et plus de risque d'utiliser v au-delà de sa portée.

Par contre, ce n'est malheureusement pas toujours possible...

Je me souviens plus (et j'ai pas envie de tout relire :lol:), est-ce que le compilateur génère, au même titre qu'un constructeur de copie par défaut, un constructeur de mouvement par défaut (et un opérateur d'assignement de mouvement par défaut également) ?

Salut !

Les opérations par défaut de déplacement seront très probablement présentes dans la version finale du C++0x, surtout au vu du dernier papier de Stroustrup et Crowl.

Pour info, il y avait déjà eu quelques papiers proposant d'ajouter la génération par défaut mais c'était à chaque fois des papiers assez vagues, présentant les différents design possibles et explicitant les difficultés, alors que cette fois le papier n'a quasiment aucun commentaire, uniquement les modifications à apporter au standard -> ça sent bon !

Par contre, le draft actuel ne définit pas encore d'opération de déplacement par défaut, et donc aucun des compilateurs ayant implémenté la sémantique de déplacement ne le fait pour le moment.

Ok merci :).

[HS] Au fait, quelqu'un en sait un peu plus sur le 'x' de c++0x? Nan parce qu'à ce train là, ça risque de finir en c++1x :aie: [/HS]

En principe, le draft sera ISO-ifié en moitié/fin 2010 si je ne m'abuse.

D'ailleurs si tu tapes C++0x sur google, la première entrée, c'est C++1x :aie:
Comme tout bon projet informatique, il est normal qu'il ait du retard sur le planning prévu :mouarf:

C++0x0A :roll:

Citation:

---

Envoyé par Alp

En principe, le draft sera ISO-ifié en moitié/fin 2010 si je ne m'abuse.

---

Par contre, l'ISOification est un processus assez lent, non ? si j'ai bien compris, il peut s'écouler environ deux ans pour passer du draft dinal à la norme proprement dite, ce qui devrait nous conduire tranquillement au C++0C/D :mrgreen: