Débat : Lumière sur les rvalue references de C++0x

Le , par Arzar, Membre émérite
Bonjour!

J'ai accès depuis quelques jours à une config Linux, et j'en profite pour tester le mode experimental c++0x de gcc. J'essaie de comprendre les rvalue references et l'impact qu'elles auront sur notre manière de coder, mais je bute sur deux problèmes :

Question 1

Première essai. Une classe "movable" mais pas copiable
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
 
struct NonCopyable 
{ 
    NonCopyable() = default; 
    NonCopyable(NonCopyable&&) = default; 
    //empeche la copie 
    NonCopyable(const NonCopyable&) = delete; 
    NonCopyable& operator=(const NonCopyable&) = delete; 
};
Mais ça ne compile pas. Gcc m'annonce qu'il est impossible d'avoir un move contructeur par défaut. Pourquoi cela ?
Ne pourrait pas avoir un move constructeur qui ferait des move membre à membre ?
Code : Sélectionner tout
1
2
3
4
5
 
NonCopyable(NonCopyable&& ncp): 
membre1(move(ncp.membre1), 
membre2(move(ncp.membre2),  
...
Question 2

A l'heure actuelle, pour appliquer un traitement sur un objet lourd, la syntaxe revient toujours plus ou moins à foo(HeavyClass&, Param1, Param2, Param3...). Esthétiquement je préfère de beaucoup la syntaxe HeavyClass foo(Param1, Param2, Param3)... mais il y a la copie.

J'avais cru comprendre que les rvalue references allaient réunir les deux mondes et nous permettre ce genre de chose :
X&& foo();
X x = foo();
Sans copie aucune. \0/

Ben il semble que non.
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
std::vector<std::string>&& parse(const std::string& s, char token) 
{ 
    std::vector<std::string> result; 
    std::string::size_type first = 0, last; 
    while (first != std::string::npos) 
    { 
        last = s.find_first_of(token, first); 
	result.push_back(s.substr(first, last - first)); 
	first = s.find_first_not_of(token, last); 
    } 
    return move(result); // move explicite 
} 
std::vector<std::string> parse = foo("Le.c++0x.c'est.l'avenir.",'.');
Segmentation fault.
Le mode debug confirme que le destructeur de result est appelé en sortant du scope de parse(), avant le move constructeur, d'où la segmentation fault. Or je croyais que le rôle même de std::move était de prolonger un peu les temporaires pour leur donner le temps de faire les opérations impliquant les rvalue reference et seulement ensuite d'être détruit. Ou cela coince-t-il ?

Merci!


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Bakura Bakura - Rédacteur http://www.developpez.com
le 12/06/2009 à 16:58
Citation Envoyé par Goten  Voir le message
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 .
Avatar de Goten Goten - Membre chevronné http://www.developpez.com
le 13/06/2009 à 11:40
Là ça serait même plutôt du teasing, et c'est pas cool du tout pour mes nerfs :p
Avatar de white_tentacle white_tentacle - Membre émérite http://www.developpez.com
le 15/06/2009 à 9:30
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
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...
Avatar de Bakura Bakura - Rédacteur http://www.developpez.com
le 02/10/2009 à 13:48
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) ?
Avatar de Arzar Arzar - Membre émérite http://www.developpez.com
le 02/10/2009 à 15:34
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.
Avatar de Bakura Bakura - Rédacteur http://www.developpez.com
le 02/10/2009 à 19:34
Ok merci .
Avatar de r0d r0d - Expert éminent http://www.developpez.com
le 08/10/2009 à 13:10
[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]
Avatar de Alp Alp - Expert éminent sénior http://www.developpez.com
le 08/10/2009 à 13:18
En principe, le draft sera ISO-ifié en moitié/fin 2010 si je ne m'abuse.
Avatar de 3DArchi 3DArchi - Rédacteur http://www.developpez.com
le 08/10/2009 à 14:12
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
Avatar de Florian Goo Florian Goo - Membre éclairé http://www.developpez.com
le 08/10/2009 à 14:49
C++0x0A
Avatar de Arzar Arzar - Membre émérite http://www.developpez.com
le 08/10/2009 à 14:56
Citation Envoyé par Alp  Voir le message
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
Offres d'emploi IT
Ingénieur conception/développement logiciel (H/F)
Opensourcing - Ile de France - Vélizy-Villacoublay (78140)
Développeur / moe cash & risk H/F
Societe Generale - Ile de France - Courbevoie
Reconversion,futur ingénieur java jee
Adaming - Alsace - Strasbourg (67000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C++