Constructeurs par défaut et constructeur par recopie.

Version imprimable

Salut!:D

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:

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:

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.

21/08/2006, 15h24
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 ?
21/08/2006, 15h25
Pragmateek

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

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

Code:

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

?
Ceci:

Code:

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:

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

21/08/2006, 15h48
roulious

Citation:

Envoyé par seriousme

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.
21/08/2006, 15h50
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:

1 2 3 std::vector<A> v(10, A(1)); v.push_back(A(2));
21/08/2006, 15h52
Pragmateek

C'est noté, merci de vos réponses.
21/08/2006, 22h19
JolyLoic

Citation:

Envoyé par Laurent Gomila

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.
22/08/2006, 12h55
Pragmateek

Citation:

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

Est-il possible de l'empêcher?

Citation:

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?
22/08/2006, 18h01
JolyLoic
Citation:

Envoyé par seriousme

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

Citation:

Envoyé par seriousme

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:

return MaClasse(Arguments);

A plus de chance de passer que faire
Code:

1 2 3 MaClass c; //... return c;
Qui lui même est bien plus simple que :
Code:

1 2 MaClass a, b; if (...) return a; else return b;
22/08/2006, 19h02
Jean-Marc.Bourguet
Citation:
Envoyé par JolyLoic

Qui lui même est bien plus simple que :

Code:

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.
25/08/2006, 16h00
loufoque
Citation:

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:

1 2 3 4 Thing foo() { return Thing(); }
Et NRVO c'est
Code:

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.