Discussion :

[Bakura]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Arzar]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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<>&&))

[Florian Goo]

Ou peut-être ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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é…

[Bakura]

Ok merci de vos réponses .

[Arzar]

Ouups pardon, Florian a raison
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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é :)
}

[Arzar]

Une dernière chose :

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 :

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

You're doing it wrong

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.

[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

[Bakura]

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 ).

[Goten]

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.

[Bakura]

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 .

[Goten]

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

[white_tentacle]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[Bakura]

Je me souviens plus (et j'ai pas envie de tout relire ), 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) ?

[Arzar]

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.

[Bakura]

Ok merci .

[r0d]

[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 [/HS]

[Alp]

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

[3DArchi]

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

[Florian Goo]

C++0x0A

[Arzar]

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