Discussion :

[Pragmateek]

Salut!

Pour créer un tableau de 10 objets:
A t[10];
utilise le constructeur par défaut.
1)Comment avoir un tableau d'objets construits avec un autre constucteur?

Ce code:

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
#include <iostream>
 
 
class A{
      public:A(){std::cout<<"default constructor"<<std::endl;}
      public:A(A const &a){std::cout<<"copy constructor"<<std::endl;}
      public:A& operator=(A const &a){std::cout<<"assignement operator"<<std::endl;}
      };
 
A f(A a){
      std::cout<<"f"<<std::endl;
      A c;
      return c;
      }
 
 
int main(void){
 
    A a;
    A b=f(a);
 
    system("pause");
    return EXIT_SUCCESS;
}

affiche:

Code :

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

1
2
3
4
default constructor
copy constructor
f
default constructor

-la première ligne correspond à la construction de "a";
-la deuxième à sa recopie lors du passage en paramètre;
-la quatrième à la construction de "c".

2)Mais pourquoi n'y a t'il pas à la suite un appel au constructeur par recopie lors de la création d'un objet temporaire au retour de la fonction?
Est-ce une optimisation?

3)Pourquoi n'y a t'il pas d'appel au constructeur par recopie lors de la construction de "b"?

Merci.

[Laurent Gomila]

1) Impossible tel quel. Tu peux toujours utiliser un std::vector si ça ne gène pas.

2) A moins que je ne dise une connerie, oui c'est une optimisation.

3) L'affectation qui suit une déclaration (ie. sur la même ligne) utilise le constructeur par copie. Si tu sépares déclaration et affectation sur deux lignes là tu auras bien un appel à l'opérateur d'affectation.

EDIT pour la question 3 : encore une optim certainement ?

[Pragmateek]

La question 3) vient d'être modifié.
Merci.

[Pragmateek]

Merci de ta réponse.
Pour les "vector" comment procéder?

Code :

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

v.assign(10,A(1));

?
Ceci:

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
#include <iostream>
#include <vector>
 
class A{
      public:A(){std::cout<<"default constructor"<<std::endl;}
      public:A(int n){std::cout<<"constructor"<<std::endl;}
      public:A(A const &a){std::cout<<"copy constructor"<<std::endl;}
      public:A& operator=(A const &a){std::cout<<"assignement operator"<<std::endl;}
      };
 
A f(A a){
      std::cout<<"f"<<std::endl;
      A c;
      return c;
      }
 
 
int main(void){
	std::vector<A> v(10);
	v.assign(10,A(1));
        system("pause");
	return EXIT_SUCCESS;
}

affichant:

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
default constructor
copy constructor
copy constructor
copy constructor
copy constructor
copy constructor
copy constructor
copy constructor
copy constructor
copy constructor
copy constructor
constructor
assignement operator
assignement operator
assignement operator
assignement operator
assignement operator
assignement operator
assignement operator
assignement operator
assignement operator
assignement operator

Pas vraiment optimisé.

[roulious]

Pas vraiment optimisé.

Non, mais il n'y a pas vraiment moyen d'optimiser plus. Lorsqu'un vector a une taille donnée, tu as la garantie que tous ses éléments ont été construits. Si tu veux différer cette construction, tu peux utiliser reserve pour allouer la mémoire puis plus tard construire effectivement les objets.

[Laurent Gomila]

La fonction membre assign, comme son nom l'indique, effectue une affectation. Si tu veux utiliser autre chose que le constructeur par défaut il faut le spécifier lors de la construction (ajout) d'un élement.

Code :

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

1
2
3
std::vector<A> v(10, A(1));
 
v.push_back(A(2));

[Pragmateek]

C'est noté, merci de vos réponses.

[JolyLoic]

2) A moins que je ne dise une connerie, oui c'est une optimisation.

C'est une optimisation qui n'en est pas une... Une optimisation n'est pas sensée changer le sens d'un programme. Or, ici, le test montre bien que le programme est modifié. Dans le cas général, un compilateur n'aurait pas le droit de faire cette optimisation.

Dans ce cas particulier, on se trouve dans un cas où le standard a spécifié qu'on avait le droit de faire ça, et si le contructeur par recopie fait des choses non standards (comme afficher du code de débug), tant pis. Cette règle du C++ est généralement appelée (à tort donc) RVO (return value optimisation). On entends aussi régulièrement parler de NRVO, named return value optimisation, ce qui n'est rien d'autre qu'une façon d'aider le compilateur à effectuer cette "optimisation" en écrivant le code d'une manière où il s'y retrouve mieux.

[Pragmateek]

Cette règle du C++ est généralement appelée (à tort donc) RVO (return value optimisation).

Est-il possible de l'empêcher?

en écrivant le code d'une manière où il s'y retrouve mieux.

Y a t'il des règles d'écritures particulières?

[JolyLoic]

Est-il possible de l'empêcher?

Pas que je sache. Tu peux regarder les options de ton compilateur, on ne sait jamais. En quoi elle te gêne ? Uniquement pour des histoires de compréhension de code, ou parce qu'elle modifie le "vrai" comportement de ton code ? Dans le second cas, j'ai envie de dire que j'ai des doutes sur l'implémentation du constructeur par recopie...

Y a t'il des règles d'écritures particulières?

Je ne les connais pas vraiment. Je crois que les compilos se débrouillent mieux quand il y a un point de sortie unique, ou encore que faire :

Code :

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

return MaClasse(Arguments);

A plus de chance de passer que faire

Code :

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

1
2
3
MaClass c;
//...
return c;

Qui lui même est bien plus simple que :

Code :

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

1
2
MaClass a, b;
if (...) return a; else return b;

[Jean-Marc.Bourguet]

Qui lui même est bien plus simple que :

Code :

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

1
2
MaClass a, b;
if (...) return a; else return b;

Je doute que le compilateur arrive à utiliser du NRVO dans ce cas: cette technique consiste à construire l'objet retourné directement à la place du temporaire. Comme ici il y a deux possibilités, c'est difficile de le faire. Ca fournit indirectement une réponse à celui qui voulait savoir comment faire pour l'empécher. Mais je me demande si la réponse est bien utile.

[loufoque]

On entends aussi régulièrement parler de NRVO, named return value optimisation, ce qui n'est rien d'autre qu'une façon d'aider le compilateur à effectuer cette "optimisation" en écrivant le code d'une manière où il s'y retrouve mieux.

Non, en fait c'est l'inverse.

La RVO c'est

Code :

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

1
2
3
4
Thing foo()
{
    return Thing();
}

Et NRVO c'est

Code :

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

1
2
3
4
5
Thing foo()
{
    Thing t;
    return t;
}

"Named" parce qu'on nomme la variable locale, qui du coup n'est plus une variable temporaire de la valeur de retour.