Liste d'initialisation C++

Bonjour,
Je cherche un tuto/exemple qui expliquerait le pourquoi du comment et le bien fond� des listes d'initialisation. De fa�on assez curieuse, il semble qu'il soit toujours recommand� de les utiliser et pourtant la plupart des exemples de code que l'on trouve sur le net ne le font pas.
Cdlt, Christian

Hello

Il n'y a pas besoin d'un tuto tr�s long pour expliquer pourquoi. Si tu "initialises" tes variables dans le code du constructeur, elles sont en fait d�j� initialis�es et tu ne fais que leur affecter une nouvelle valeur.

Cela se voit tr�s bien avec les r�f�rences qui doivent obligatoirement �tre initialis�es. Le code suivant ne compile pas:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class refholder { int & ref_;   public: refholder(int & ref) { ref_ = ref; } };   int main() { return 0; }

---

Code:

---

1 2	test.cpp: In constructor 'refholder::refholder(int&)': test.cpp:6: error: uninitialized reference member 'refholder::ref_'

---

Alors que ce code est correct:

Code:

---

1 2 3 4 5 6 7 8 9 10

class refholder { int & ref_;   public: refholder(int & ref) : ref_(ref) {} };   int main() { return 0; }

---

Cela sera �galement valable pour les membres qui n'ont pas de constructeur par d�faut. Code incorrect:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class A { int i_;   public: A(int & i) : i_(i) {} };   class B { A a_;   public: B(int & b) { a_ = A(b); } };   int main() { return 0; }

---

Code:

---

1 2 3 4

test.cpp: In constructor 'B::B(int&)': test.cpp:16: error: no matching function for call to 'A::A()' test.cpp:6: note: candidates are: A::A(int&) test.cpp:2: note: A::A(const A&)

---

Version correcte :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class A { int i_;   public: A(int & i) : i_(i) {} };   class B { A a_;   public: B(int & b) : a_(b) {} };   int main() { return 0; }

---

Il est donc nettement plus propre d'utiliser les listes d'initialisation. A noter qu'avec C++11, on peut �galement initialiser les membres au niveau de leur d�claration dans le header (ce qui est int�ressant pour les membres simples comme les types de base ou les pointeurs, � �viter avec des types plus complexes pour limiter les d�pendances du header).

Enfin, la liste d'initialisation est le seul moyen d'appeler les constructeurs parents avec des param�tres.

Citation:

---

Envoy� par coberle

la plupart des exemples de code que l'on trouve sur le net ne le font pas.

---

C'est que vous cherchez mal. L'utilisation de la liste d'initialisation de fa�on syst�matique est admise par la communaut� depuis bien longtemps, et c'est donc le cas de tout bon code que l'on trouve sur internet.

Un peu de litt�rature:
http://www.parashift.com/c++-faq-lite/init-lists.html
http://forums.codeguru.com/showthrea...hould-I-use-it

Un peu plus avanc�, pour le probl�me des exceptions:
http://www.gotw.ca/gotw/066.htm

Ne serait-ce pas une confusion avec les std::initializer-list?

L'exemple de la liste d'initialisation dans le cas d'une r�f�rence est une exception: on ne peut initialiser une r�f�rence que de cette mani�re.
Ca ne rend pas la liste d'initialisation plus valable dans le cas des autres variables. Est-ce qu'on y gagne quelque chose en termes de performances?
Personnellement, je renonce parfois � la liste d'initialisation quand, pour des raisons de lisibilit�, je veux regrouper certaines intialisations avec leur traitement (toujours dans le constructeur) s'il y en a.
C'est pas plus intelligent d'utiliser les deux solutions de mani�re pragmatique?

Citation:

---

Envoy� par jblecanard

Si tu "initialises" tes variables dans le code du constructeur, elles sont en fait d�j� initialis�es et tu ne fais que leur affecter une nouvelle valeur.

---

(HS : tu gagnes un deuxi�me trophet "d�t�rage de post" - mais plus petit que le premier)

La phrase de jblecanard est pourtant claire : si tu n'utilises pas la liste d'initialisation, ce n'est pas une initialisation mais une affectation. Tu initialises une premi�re fois tes variables, puis tu les modifies.

Donc c'est une mauvaise pratique et un probl�me de performance de ne pas utiliser les listes d'initilisation

Citation:

---

Envoy� par Armulis

Personnellement, je renonce parfois � la liste d'initialisation quand, pour des raisons de lisibilit�, je veux regrouper certaines intialisations avec leur traitement (toujours dans le constructeur) s'il y en a.

---

Est-ce que tu peux donner un exemple de ce que tu entends par l� ?
Parce que depuis qu'il y a les delegating constructors, qui s'ajoutent � la possibilit� d'initialiser � l'aide d'une fonction, j'ai du mal � voir des cas o� l'�criture d'une liste d'une liste d'initialisation est plus complexe que celle du body d'un constructeur.

Le seul cas que je vois comme �a, c'est si tu as envie d'initialiser de mani�re non triviale deux champs de ta classe � partir d'un m�me param�tre du constructeur (et que ces deux champs n'ont pas int�r�t � �tre externalis�s dans une classe d�di�e).

Citation:

---

Envoy� par Armulis

Ca ne rend pas la liste d'initialisation plus valable dans le cas des autres variables. Est-ce qu'on y gagne quelque chose en termes de performances?

---

C'est pourtant une question de bon sens : vaut-il mieux seulement initialiser une variable ou bien l'initialiser puis lui affecter une valeur ? Dans le cas des entiers et pointeurs, il est vrai que la diff�rence est faible voire nulle puisque l'initialisation par d�faut n'affecte pas la valeur. En revanche pour d'autres variables, oui, on gagne en performance. La preuve :

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 25 26 27 28 29 30 31 32 33 34

#include <vector> #include <chrono> #include <iostream>   using collec_type = std::vector<int>;   class A { collec_type v_; public: A() : v_ {1,2,4,4,5,6,7,8,9} {} };   class B { collec_type v_; public: B() { v_ = collec_type({1,2,4,4,5,6,7,8,9}); } };   int main() { using namespace std::chrono; constexpr size_t nb_iter = 1e7;   auto t1 = high_resolution_clock::now(); for(size_t i = 0; i < nb_iter; ++i) A a; auto t2 = high_resolution_clock::now(); for(size_t i = 0; i < nb_iter; ++i) B b; auto t3 = high_resolution_clock::now();   std::cout << "Init list: " << duration_cast<milliseconds>(t2-t1).count() << "ms\n"; std::cout << "Ctor body: " << duration_cast<milliseconds>(t3-t2).count() << "ms\n";   }

---

Seule diff�rence entre A et B : A initiliase via une liste d'initialisation et B via une affectation dans le corps du constructeur. En debug sur la machine que j'utilise actuellement, la diff�rence est frappante :

GCC 4.9, debug

Citation:

---

Init list: 2582ms
Ctor body: 4833ms

---

Clang 3.5, debug

Citation:

---

Init list: 2128ms
Ctor body: 3672ms

---

En optilmis� (-O2), je porte le nombre d'it�rations � 1e8 car un effet de bord peut faire croire que la version liste d'initialisation est plus lente de quelques millisecondes. On obtient :

GGC 4.9, O2

Citation:

---

Init list: 3275ms
Ctor body: 3797ms

---

Clang 3.5, 02

Citation:

---

Init list: 3257ms
Ctor body: 3755ms

---

Bien s�r ces r�sultats se reproduisent sur des runs successifs. En -O3, il n'y a pas de diff�rence significative, le test est trop simple et les compilos optimisent les deux objets de mani�re similaire. Quoi qu'il en soit, ne pas utiliser les listes d'initialisation d�lib�r�ment sans que cela ne se justifie fonctionnellement est une mauvaise habitude � perdre.

Salut,

Citation:

---

Envoy� par Armulis

L'exemple de la liste d'initialisation dans le cas d'une r�f�rence est une exception: on ne peut initialiser une r�f�rence que de cette mani�re.
Ca ne rend pas la liste d'initialisation plus valable dans le cas des autres variables. Est-ce qu'on y gagne quelque chose en termes de performances?
Personnellement, je renonce parfois � la liste d'initialisation quand, pour des raisons de lisibilit�, je veux regrouper certaines intialisations avec leur traitement (toujours dans le constructeur) s'il y en a.
C'est pas plus intelligent d'utiliser les deux solutions de mani�re pragmatique?

---

En un mot : non!!!

De mani�re g�n�rale, tu devrais toujours utiliser la liste d'initialisation, point barre. Si tu as "quelque chose" � faire en plus dans ton constructeur, fait le, mais pourquoi voudrais tu renoncer � la liste d'initialisation alors que, au final, c'est la seule m�thode qui fonctionne de mani�re syst�matique, avec des valeurs et avec des r�f�rences, et qui �vite, de plus, des copies inutiles parfois tr�s lourdes en ressources :question:

De plus, on peut �galement citer le cas des classes ayant s�mantique d'entit� qui ne sont, typiquement, ni copiables ni affectables et pour lesquelles ont peu malgr� tout d'envisager l'utilisation sous la forme de membre cr�� par valeur et non de membre prenant la forme de r�f�rences ou de pointeurs... La liste d'initialisation sera, l� encore, la seule solution envisageable !!!

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

class Base{ public: virtual ~Base(); Base(Base const &) = delete; Base & opertor = (Base const &) = delete; }; class Derivee : public Base{ public: Derivee():Derivee(0){} Derivee(int value):value_(value){} private: int value_; }; class Utilisatrice{ public: Utilisatrice(int i):d_(i){} // OK: constructeur prenant un int est appelé /*   Utilisatrice(int i){   d_ = Derivee(i); // erreur: copie et affectation interdite   }   */ private: Derivee d_; };

---

Note : ce n'est pas parce que Derivee h�rite de Base que tu ne peut envisager que l'utilisation d'un pointeur sur le type Base et recourir syst�matiquement � l'allocation dynamique de la m�moire : si tu sais pertinemment bien que tu as besoin d'un objet de type Derivee, il n'y a rien --hormis le fonctionnement de certaines biblioth�que -- qui puisse t'interdire de cr�er une instance "classique" de ta classe ;)

En gros, l'id�e g�n�rale de cette liste d'initialisation, c'est comme pour le mot-cl� auto: "toute chose �gale par ailleurs".
L'id�e �tant que ce n'est jamais pire d'utiliser la liste d'initialisation que de le corps du constructeur, alors autant le faire tout le temps.