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.