Discussion :

[r0d]

Bonjour,

je cherche à forcer la copie d'une instance sur un retour de fonction, mais je n'y arrive pas !
Je sais que ça n'a pas vraiment de sens, mais c'est juste parce que je voudrais tester un truc.
Prenons le code suivant:

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
class Foo
{
public:
	Foo(int num = 10) : m_num(num) {}
 
	Foo(const Foo& other) : m_num(other.m_num) {}
	Foo(const Foo&& other) = delete;
 
	Foo& operator = (const Foo& other) = delete;
	Foo& operator = (const Foo&& other) = delete;
 
	int m_num = 5;
};
 
Foo f(const Foo& foo1) 
{
	return Foo(foo1.m_num + 1);
}
 
int main()
{
	Foo foo1;
	Foo foo2 = f(foo1);
}

Ça ne compile pas : il veut absolument son move ctor !

Code :

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

Error	C2280	'Foo::Foo(const Foo &&)': attempting to reference a deleted function

Je travaille avec Visual Studio 2017.
Merci par avance

[Bktero]

Ca compile avec mingw64... mais clang-tidy me mets des erreurs similaires aux tiennes...

[dalfab]

Bonjour,

En C++14 ça ne doit pas compiler (il faut une copie qui a été interdite), par contre en C++17 ça devrait compiler (on doit créer directement l'objet résultat.)

[Bousk]

Peut-être stupide mais essayes de retourner un const ? Le const devrait empêcher le déplacement.
Après vue que tout va dans le sens d'éliminer les copies (move, RVO), vouloir le forcer est un peu étrange et pas forcément simple.
Ne peux-tu pas passer une instance en paramètre out ? Créer un objet container ?

Foo& operator () (const Foo& other) = delete; ce n'est pas plutôt l'operator = pour empêcher la copie que tu veux bloquer ?

[Bktero]

par contre en C++17 ça devrait compiler

Je compile effectivement en C++17 !

Et je viens de tester en C++14 : ça ne compile pas ! Bien vu !

Tu as une explication précise à ce cas à nous donner stp ?

[r0d]

Foo& operator () (const Foo& other) = delete; ce n'est pas plutôt l'operator = pour empêcher la copie que tu veux bloauer ?

Bien vu; j'ai édité.

Peut-être stupide mais essayes de retourner un const ? Le const devrait empêcher le déplacement.

nope, ça change rien avec VS 2017.

Après vue que tout va dans le sens d'éliminer les copies (move, RVO), vouloir le forcer est un peu étrange et pas forcément simple.
Ne peux-tu pas passer une instance en paramètre out ? Créer un objet container ?

Ben oui le problème est bien là : j'essaie de faire quelque chose dont les concepteurs du langage mettent tout en œuvre depuis plusieurs d'années pour que je ne puisse pas le faire ! ^_^
J'aimerais éviter de passer par des intermédiaires. En fait, c'est pour "tester" notre profiler (un outil interne). J'ai l'impression qu'il fait des trucs bizarres et j'essaie de le piéger. Il fait une sauce à lui qui mélange analyse statique et des trucs au runtime.

[Bousk]

Et retourner un pointeur ?
Tu peux ensuite déréférencer le pointeur pour faire ta copie. Avec unique_ptr tu n'as pas à te soucier de la mémoire.

[dalfab]

Tu as une explication précise à ce cas à nous donner stp ?

En fait j'ai répondu un peu vite. En C++14 ça devrait aussi compiler car le constructeur par déplacement n'existe pas, mais il devrait pouvoir se rabattre en utilisant le constructeur de copie qui lui est accessible. En C++17 il n'a même pas besoin de regarder les constructeurs de copie, on sait créer l'objet donc on peut avoir une fonction qui retourne l'objet, la RVO est désormais obligatoire même si l'objet n'a pas de constructeur de copie.
La ligne return f( foo1.m_num + 1 ); peut être remplacée par return { foo1.m_num + 1 };, on contourne ici la construction explicite d'un objet à copier, mais pourquoi le constructeur par copie ne serait pas utilisé ici? Je ne vois pas pourquoi c'est refusé.
La ligne Foo foo2 = f(foo1); devrait être optimisée, sinon peut toujours écrire Foo&& foo2 = f(foo1); pour que foo2 corresponde à ce qui est retourné par la fonction f.

[jo_link_noir]

En fait j'ai répondu un peu vite. En C++14 ça devrait aussi compiler car le constructeur par déplacement n'existe pas, mais il devrait pouvoir se rabattre en utilisant le constructeur de copie qui lui est accessible.

Ce n'est pas qu'il n'existe pas, bien au contraire, c'est qu'il n'est pas autorisé. Le même comportement existe avec n'importe quelles fonctions.

Code :

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

1
2
3
4
5
6
void foo(int const&){}
void foo(int const&&) = delete;
 
foo(1); // refusé
int i;
foo(i); // ok

Pour que le constructeur de déplacement ne soit pas utilisé, il faut uniquement le constructeur de copie.

La ligne return f( foo1.m_num + 1 ); peut être remplacée par return { foo1.m_num + 1 };, on contourne ici la construction explicite d'un objet à copier, mais pourquoi le constructeur par copie ne serait pas utilisé ici? Je ne vois pas pourquoi c'est refusé.

Cette forme fait aussi partie de la RVO. En fait, le changement en 17 ne s'applique pas spécialement à la RVO, mais à l’élision de copie en général.

Code :

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

1
2
3
4
5
6
Foo f = Foo{Foo{Foo{}}}; // élision, pas de copie
Foo f(const Foo& foo1)
{
    Foo f(foo1.m_num + 1);
    return f;  // élision (valide aussi en 14)
}

Pour empêcher la RVO, il y a l'option -fno-elide-constructors (ou sous forme d'attribut) dans clang et gcc, mais je ne sais pas s'il existe un équivalent sur msvc. Sinon, on peut caster en référence constante...

Code :

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

1
2
3
4
Foo f(const Foo& foo1)
{
    return static_cast<Foo const&>(Foo(foo1.m_num + 1));
}