Discussion :

[guillaume07]

Ecnore une question autour des concept des Rvalue references et du move semantics :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
struct Foo
{
	int n;
	explicit Foo(int m):n(m)
	{
		std::cout << "constructeur\n";
	} 
	Foo(const Foo& n)
	{ 
		std::cout << "constructeur copie\n";
	}
	Foo(Foo&& n)
	{ 
		std::cout << "constructeur move\n";
	}
};
 
Foo make()
{
	return Foo(3);
}
 
int main()
{ 	  	 
	Foo po( make() );  //ok mais affiche uniquement constructeur ?!
	std::cout << " " << po.n;
	system("pause");
 
}
 
int main()
{ 	  	 
	Foo po( move(make()) );  //passe bien dans le move ctor
	std::cout << " " << po.n; // affiche n'importe quoi?!
	system("pause");
 
}

Deux questions :

pourquoi dans le premier main , on ne passe ni dans le ctor de copie ni dans le ctor de move ?

pourquoi dans le 2eme cas, ça affiche n'importe quoi ?

Merci.

[Flob90]

1/ NRVO + Copy-Elision : Le compilateur choisit de ne pas faire les copies intuiles, c'est à dire celles à la sortie de la fonction, et celle avec le copy_ctor, il créé directement l'objet sur place.

2/ Le NRVO agit une première fois à la sortie de la fonction (sinon tu aurais ctor copy_ctor, et pas seulement ctor), puis tu utilises std::move donc il n'y a plus de copy-elision possible, et le move_ctor est utilisé.

Pour la valeur c'est normal, ca a beau être une move_ctor, ca reste un contructeur, si tu ne donnes pas de valeur à ton attribut il est non-initialisé, et donc ca valeur c'est n'importe quoi.

Pour ce qui concerne la sémantique de mouvement et les rref, il y a une séries d'articles sur le sujet sur cppnext, avec un rappel sur le (N)RVO et la copy-ellision au début. (Et il y a plusieurs exemples qui permettent de bien comprendre)

[guillaume07]

très clair merci.
j'étais passé à côté de la copy-Elision

du coup ça me laisse perplexe quand à l'utilité réel de la move semantics, ok pour le move quand on veut forcer une lvalue en rvalue mais à part ça ...??

[Joel F]

très clair merci.
j'étais passé à côté de la copy-Elision

du coup ça me laisse perplexe quand à l'utilité réel de la move semantics, ok pour le move quand on veut forcer une lvalue en rvalue mais à part ça ...??

La move semantic reste utile pour la construction par vol de ressource. Un temporaire est passé a un op= ou un ctor, tu echange les ressources et hop.

[guillaume07]

on est bien d'accord que dans un code comme celui là :

Code :

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

1
2
3
4
5
6
7
8
 
std::vector<std::string> v;
{
std::string s = "sometext";
v.push_back( std::move(s) );
//s ne doit pas être accédé ??
}
//v[0] est toujours valide ??

[Jean-Marc.Bourguet]

on est bien d'accord que dans un code comme celui là :

Code :

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

1
2
3
4
5
6
7
8
 
std::vector<std::string> v;
{
std::string s = "sometext";
v.push_back( std::move(s) );
//s ne doit pas être accédé ??
}
//v[0] est toujours valide ??

J'ai pas suivi ça de trop trop près (Loic?), mais ce qu'on garanti pour les types standards après qu'ils aient ete deplaces, ce qu'on exige des types arguments template de la SL et ce qui est fournit d'office et dans quelles circonstances pour les types declares par l'utilisateur était un des gros sujets de discussion lors du dernier meeting du comité.

Autrement dit, même s'il n'est pas impossible que tu puisses faire quelque chose avec s, ne fait rien pour le moment, c'est pas impossible que ca ait change, c'est pas impossible que ca change.

[Goten]

Non, s ne doit pas être accédé, tu lui a volé ses ressources. Quand tu vois un move, tu touches plus à la ressource qui a été bougé. (et oui v[0] est toujours valide).

(note que ma version de la STL ne fournit pas de constructeur prenant une rvalue ref ni d'op=)

[Arzar]

Non, s ne doit pas être accédé, tu lui a volé ses ressources.

Jean-Marc.Bourguet a raison, on ne peut pas être aussi affirmatif Goten, car l'état d'un objet que l'on vient de déplacer a toujours été sujet à débat au comité et encore maintenant n'est pas fixé. (Je fais pas parti du comité hein , c'est ce j'en déduis à la lecture des papiers) Il y a d'ailleurs dans le dernier mailing un papier de Stroustrup qui tente de faire un résumé et propose une solution de plus.

I think that the original idea was that a moved-from object would never be used again. The canonical example was “return x;” where move would save us from an expensive copy of x followed by the destruction of x. It follows that the moved-from state must be destructible. It was soon decided that in addition, it would help programmers (especially library builders) if it was possible to assign to a moved-from object. However, even that was not obvious to all and attempts to require further guarantees for the moved-from state elicited strong opposition. The consensus seems to be that a moved-from state must be “valid but unspecified” exactly as an object after a throw under the basic guarantee, but that nothing more can be guaranteed (except possibly for some specific type).

The obvious state of a moved-from object is the “empty state.” The snag is that for some types there is no obvious “empty state” (e.g., consider proxies). How would we know if there was an empty state for a type X? Consider default construction. If there is a default constructor, we have an empty state – and by implication – we have an excellent candidate for the moved-from state. Assuming that we equate “establishing the invariant” with “constructing”, the existence of a default constructor ensures that there is a way to establish the invariant without running multiple operations or supplying arguments. Ignoring details, the obvious default move becomes:
1. Move each element
2. Default construct the moved-from object
This observation leads to the idea: Generate a move operation for X only if we can default construct an X. There may be other constraints on generation; in particular, the ones I suggested in N3174. Let’s explore.

[Goten]

Jean-Marc.Bourguet a raison, on ne peut pas être aussi affirmatif Goten, car l'état d'un objet que l'on vient de déplacer a toujours été sujet à débat au comité et encore maintenant n'est pas fixé.

"Rule of thumb" pour éviter les ennuis.. C'est pas incompatible avec ce que dis Jean-Marc, c'est juste que pour éviter les ennuis je préfère le dire clairement comme ça. (par exemple, dans ma version de la SL, un std::vector à l'heure actuelle ses pointeurs pointent vers NULL après qu'il ai été déplacé).
J'avais mal lu ce que disais Jean-Marc mais il en était arriver à la même conclusion que moi, dans le doute, ne pas s'en servir.

[Arzar]

Ok, désolé, j'avais mal compris. En effet, dans le doute vaut mieux s'abstenir pour le moment.