Discussion :

[coberle]

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

[jblecanard]

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 :

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

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 :

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

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 :

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

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 :

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

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

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 :

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

[mintho carmo]

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

[r0d]

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

[ternel]

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

[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?

[JolyLoic]

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

[jblecanard]

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 :

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

Init list: 2582ms
Ctor body: 4833ms

Clang 3.5, debug

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

Init list: 3275ms
Ctor body: 3797ms

Clang 3.5, 02

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.

[koala01]

Salut,

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

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 :

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