Je bute sur ce (:) cidessous

Code:

---

1 2 3 4 5 6 7

Employee::Employee( const string &first, const string &last, const Date &dateOfBirth, const Date &dateOfHire ) : firstName( first ), // initialize firstName lastName( last ), // initialize lastName birthDate( dateOfBirth ), // initialize birthDate hireDate( dateOfHire ) // initialize hireDate

---

je vois bien que c'est une initialisation de data-members de la classe, mais où cela est-il bien décrit ?

J'ai du mal à saisir la question. Tu demandes quel chapitre du livre de Bjarne Stroustrup parle des initialiseurs de membres?

C'est la liste d'initialisation du constructeur

regarde ici et là pour ce point particulier

Salut,
Ce que tu décris s'appelle une liste d'initialisation.
C'est équivalent à :

Code:

---

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

class Employee { public: Employee( const string &first, const string &last, const Date &dateOfBirth, const Date &dateOfHire ) { firstName = first ; // initialize firstName lastName = last ; // initialize lastName birthDate = dateOfBirth; // initialize birthDate hireDate = dateOfHire; // initialize hireDate } private: string first; string last; Date dateOfBirth; Date dateOfHire; };

---

Mais en beaucoup mieux. :king:
Si tu débutes en c++ je te conseille de ne pas trop chercher à comprendre et d'appliquer toujours cette règle :

Quand on crée une classe, il faut TOUJOURS créer en même temps en constructeur par défaut qui aura TOUJOURS une liste d'initialisation avec TOUS les membres initialisés à zéro (ou une autre valeur, voulant dire :"pas encore utilisé").

Example

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 Toto { public:   Toto(): membre_1(0), membre_2(0.0f), membre_3(A(0, "default")) // Appel du constructeur d'une classe A pas décrite ici. { }   Toto(int var1, float var2, const A& var3): membre_1(var1), membre_2(var2), membre_3(var3) { }   private: int membre1_; float membre2_; A membre3_; // Instance d'une classe A. };

---

Il y a plein de bonne raisons:
1) Plus sécurisé. La hantise de tout développeur c++, c'est la variable mal initialisée, qui provoque des comportements et des crashs inexplicables. En initialisant TOUJOURS et sans se poser de questions tu t'éviteras bien des ennuis.
2) C'est plus efficace. Il me semble qu'il y a des copies temporaires en moins avec la liste d'initialisation. Voir pour les détails "Effective c++"
3) Meilleur comportement en cas d'héritage. Je ne me souviens plus exactement en quoi, voir "Effective c++"

Et une raison perso et subjective :
4) C'est joli. :D Les variables sont bien alignées, on voit d'un seul coup d'œil ce qui se passe.

Merci pour ces réponses claires et nettes.
Ce double point me posait quelques problèmes avec son utilisation en héritage.
J'ai cependant toujours été un défenseur en C de choses claires et nettes et bien commentés.
J'opterais donc plus-tôt pour

Code:

---

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

class Employee { public: Employee( const string &first, const string &last, const Date &dateOfBirth, const Date &dateOfHire ) { firstName = first ; // initialize firstName lastName = last ; // initialize lastName birthDate = dateOfBirth; // initialize birthDate hireDate = dateOfHire; // initialize hireDate } private: string first; string last; Date dateOfBirth; Date dateOfHire; };

---

Je connaissais pas Bruce-Eckel, maintenant c'est fait. La version en Anglais est disponible sur son site. Et bon travail des traducteurs :king:

Citation:

---

Envoyé par mess-mate

J'ai cependant toujours été un défenseur en C de choses claires et nettes et bien commentés.
J'opterais donc plus-tôt pour

---

Ce deux phrases me semblent en contradiction...

La distinction entre affectation et initialisation est fondamentale en C++, et avec l'écriture que tu sembles préférer, tu utilises une affectation pour initialiser. C'est inefficace, ce n'est pas forcément possible (et si une des données à initialiser n'a pas de constructeur par défaut ? ou si elle n'est pas assignable (instance constante, classe non copiable...) ?) mais surtout elle confond eux opération qui ont peu de chose en commun, sauf une syntaxe semblable dans certains cas.

Bonjour,

Il me semble que la différence entre les deux codes et que dans le premier cas (avec les : au niveau du constructeur) la variable est initialisée c'est a dire que la valeur first est mis dans la variable firstName dès sa création alors qu'avec le deuxième bout de code la variable est créée puis on lui affecte ensuite la valeur firstname dans le constructeur. Il est conseillé en C/C++ de toujours initialisé les variables dès leur création pour ne pas avoir de variable avec une inconnue. Voici un exemple simple pour mieux comprendre :

Code:

---

1 2 3 4 5

int i = 0; //on initialise la variable a sa création   int i; //on crée la variable i = 0; //on lui affecte une valeur

---

Je prends garde de vos remarques .....
Mais mes neurones ont encore du mal avec ces classes.
Et je crains que je vais devoir revenir sur ma position à fur et mesure que j'avancerais.

Citation:

---

Envoyé par Keweed

Bonjour,

Il me semble que la différence entre les deux codes et que dans le premier cas (avec les : au niveau du constructeur) la variable est initialisée c'est a dire que la valeur first est mis dans la variable firstName dès sa création alors qu'avec le deuxième bout de code la variable est créée puis on lui affecte ensuite la valeur firstname dans le constructeur. Il est conseillé en C/C++ de toujours initialisé les variables dès leur création pour ne pas avoir de variable avec une inconnue. Voici un exemple simple pour mieux comprendre :

Code:

---

1 2 3 4 5

int i = 0; //on initialise la variable a sa création   int i; //on crée la variable i = 0; //on lui affecte une valeur

---

---

Ce n'est vrai que dans le cas des types primitifs. Dans le cas des classes la variable sera initialisée en appelant son constructeur par défaut puis on lui assignera une nouvelle valeur.
Ça peut poser problème au niveau de la syntaxe de par la conception des classes comme l'a souligné Loic, mais c'est aussi moins optimisé. Par exemple, dans le cas d'un std::string, on pourrait supposer que certaines implémentations allouent un bloc de mémoire de 1 byte dans leur constructeur par défaut (pour stocker une chaine vide avec son 0 de fin de chaine). Donc initialiser via le constructeur par défaut puis assigner une nouvelle chaine est moins efficace que d'initialiser directement à la bonne valeur puisque ça pourrait nécessiter deux malloc au lieux d'un.

En gros il est indispensable de maitriser les listes d'initialisation pour savoir programmer en C++ (comme plein d'autres choses, hé oui c'est difficile à apprendre comme langage :D).

et surtout il faut bien comprendre ce mécanisme parce qu'il est nécessaire en cas d'héritage par exemple

Moi je trouve que la liste d'initialisation est lourde à gérer quand on a plusieurs constructeurs. Il faut faire autant de listes qu'il y a de constructeurs, ce qui alourdi l'écriture. Alors que l'appel à une méthode qui méthode qui réalise les initialisations, c'est plus pratique, même si c'est moins beau d'un point de vu conceptuel.

Salut,

Citation:

---

Envoyé par Arzar

Quand on crée une classe, il faut TOUJOURS créer en même temps en constructeur par défaut qui aura TOUJOURS une liste d'initialisation avec TOUS les membres initialisés à zéro (ou une autre valeur, voulant dire :"pas encore utilisé").

---

Personnellement je ne crée pas de constructeur par défaut quand je n'en ai pas vraiment besoin (et c'est très rare).
Ça obligerait à maintenir et tester cet état "pas encore utilisé" ce qui est source d'erreurs, pollue le code utile et ne sert en général à rien.

MAT.

Citation:

---

Envoyé par Keweed

Bonjour,

Il me semble que la différence entre les deux codes et que dans le premier cas (avec les : au niveau du constructeur) la variable est initialisée c'est a dire que la valeur first est mis dans la variable firstName dès sa création alors qu'avec le deuxième bout de code la variable est créée puis on lui affecte ensuite la valeur firstname dans le constructeur. Il est conseillé en C/C++ de toujours initialisé les variables dès leur création pour ne pas avoir de variable avec une inconnue. Voici un exemple simple pour mieux comprendre :

Code:

---

1 2 3 4 5

int i = 0; //on initialise la variable a sa création   int i; //on crée la variable i = 0; //on lui affecte une valeur

---

---

En fait, c'est bien plus complexe que cela...

Le but du constructeur, tout le mond l'aura compris, c'est de fournir un objet "directement utilisable".

Le problème, c'est que, pour que l'objet concerné puisse être utilisable, il faut créer et initialiser les... les variables membres qui le composent, et donc, qu'un des constructeurs de ces variable sera systématiquement appelé.

Or, dans une classe "bien formée", et même si tu ne définis toi même aucun constructeur, tu en trouvera d'office deux:

1. Le constructeur par défaut (ne prenant aucun paramètre à l'origine)
2. le constructeur par copie (prenant en paramètre un référence constante sur l'objet lui-même et dont el comportement par défaut est de copier les différents membre "membre à membre").

Le fait est que, si tu ne précise pas le constructeur qu'il faut appeler pour un membre dans la liste d'initialisation d'un objet, ce sera - d'office - le constructeur par défaut ne prenant aucun paramètre que le compilateur essayera d'appeler, et c'est là que les choses commencent à coincer...

En effet, si tu as une classe proche de

Code:

---

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

class MySimpleClass { public: MySimpleClass(const std::string& s) /* le constructeur de str est   * appelé ici   */ { /* ici, tu affecte une valeur à str précédemment créé   */ str = s; } private: std::string str; }

---

Pour construire str, il n'y a pas de problème: la classe std::string présente suffisemment de constructeurs différents pour pouvoir travailler à peu près comme tu le souhaite.

Par contre, le compilateur ne connait que deux constructeurs pour MySimpleClass qui sont:

• MySimpleClass::MySimpleClass(const std::string&) et
• MySimpleClass::MySimpleClass(const MySimpleClass&)

Aussi, quand tu va souhaiter utiliser MySimpleClass comme membre d'une autre classe, par exemple, sous la forme de:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

/* !!! Ce code ne compilera pas !!! */ class MyOtherClass { public: MyOtherClass(const MySimpleClass& sc) { msc = sc; } private: MySimpleClass msc; };

---

tu va avoir un problème: il n'existe pas de constructeur de MySimpleClass qui ne prend pas d'argument... et le compilateur, qui aura remplacé le code du constructeur en quelque chose proche de

Code:

---

1 2 3 4

MyOtherClass::MyOtherClass(const MySimpleClass& sc):msc() { msc = sc; }

---

parce que c'est "la seule manière que nous lui avons apprise" se plaindra... que MySimpleClass::MySimpleClass() n'existe pas.

Pire, pour l'instant, si tu te contente d'utiliser les listes d'initialisations et donc de modifier le constructeur de MyOtherClass en

Code:

---

1 2 3 4 5 6

MyOtherClass::MyOtherClass(const MySimpleClass& sc):msc(sc) { /* c'est devenu inutile: msc est initialisé   * msc = sc;   */ }

---

Tu me dira qu'il te "suffira" de définir un constructeur ne prenant pas d'argument pour MySimpleClass (voire, même, dans ce cas, de fournir une valeur par défaut pour l'argument sc), et tu n'aura - dans une certaine mesure - pas tord.

Le simple fait de modifier MySimpleClass en

Code:

---

1 2 3 4 5 6 7 8 9 10

class MySimpleClass { public: MySimpleClass(const std::string& s="") { str = s; } private: std::string str; };

---

permet de disposer d'un constructeur ne prenant pas d'argument, et donc d'écrire le constructeur de MyOtherClass sous la forme de

Code:

---

1 2 3 4

MyOtherClass::MyOtherClass(const MySimpleClass& sc) { msc = sc; }

---

Ce n'est déjà pas si mal, non :question:

en plus, un code proche de

Code:

---

1 2 3 4 5 6 7 8

void foo() { /* s aurait pu etre définie de n'importe quelle manière, y compris   * sur base d'éléments extérieurs ;)   */ std::string s("une chaine destinee a MySimpleClass"); MyOtherClass moc(s); }

---

fonctionnera car le constructeur de MySimpleClass agit comme un opérateur de conversion implicite de std::string en MySimpleClass, et que l'utilisation d'une référence constante permet de créer une variable temporaire de type MySimpleClass à partir d'un référence constante sur une chaine de caractères std::string...

Citation:

---

Envoyé par le naif en son lui-même

Mais que veut le peuple :question: j'écris un constructeur, et j'obtiens deux manière d'initialiser MySimpleClass :D:D

---

Sauf que, fort de cette constatation, tu en viens un peu plus tard - pour une raison qui ne tient qu'à toi - à vouloir écrire un code proche de

Code:

---

1 2 3 4

void bar() { MyOtherClass moc("une chaine destinee a MySimpleClass"); }

---

parce que la chaine qui doit initialilser MyOtherClass::msc ne changera pas pour cette fonction particulière.

Et là, tu te fais royalement jeter par le compilateur car il n'y a aucun constructeur de MyOtherClass qui accepte, comme parmamètre, un const char*...

Ben, la solution est toute trouvée: ajoutons un constructeur à MyOtherClass qui soit compatible avec un const char* ;)

Aussi tot dit, aussi tot fait... Si l'on n'utilise pas la liste d'initialisation, cela donnerait

Code:

---

1 2 3 4 5

MyOtherClass::MyOtherClass(const std::string& s) { /* ben non, ca va pas... MySimpleClass::str est privé */ msc.str = s; }

---

Pour résoudre ce problème, et toujours sans passer par la liste d'initialisation, il y a deux solutions:

1. Créer un mutateur pour le membre str de MySimpleClass
2. Déclarer MyOtherClass amie de MySimpleClass

Mais aucune des solutions n'est réellement satisfaisante en soi...

D'abord parce que la création d'un mutateur public proche de

Code:

---

1 2 3 4 5

void MySimpleClass::setStr(const std::string& s) { /*vérifications éventuelles */ str=s; }

---

permettra de modifier la valeur de str... partout, et que ce n'est peut etre pas ce que l'on veut

Ensuite, le fait de déclarer MyOtherClass amie de MySimpleClass résoud le problème spécifique à MyOtherClass, mais... que le problème se posera à nouveau le jour où tu voudra créer une troisième classe dont un membre sera... un objet de type MySimpleClass...

Tout cela a pour but de prouver que la liste d'initialisation, bien que le principe soit difficile à comprendre, est - d'un point de vue purement pratique - le meilleur choix "dans toutes circonstances" ;)

Un autre point de vue qui pourrait être abordé serait le point de vue des "performances pures".

Comme j'ai déjà écrit un roman, je me contenterai de dire que, sur des classes dont les membres sont des collections d'objets, le fait d'écrire un constructeur sous la forme (générique) de

Code:

---

1 2 3 4

Type::Type(const AutreType& arg) { var = arg; }

---

provoquera souvent la copie de l'argument et sa destruction en sortie de fonction, avec tout ce que cela implique dont, principalement le fait que:

1. Même si ce n'est que pour un moment finalement court, la mémoire contient deux copies strictement identiques de ce qui est représenté par arg, et on *risque* toujours de ne pas disposer d'assez de mémoire pour y arriver
2. Les mécanisme de copie et de destruction prennent du temps et cela peut finir par représenter un "goulot d'étranglement" si les appels sont répétés

[NOTA]:Même les type primitifs disposent de "pseudo constructeurs"...

Il est donc tout à fait possible d'initialiser les membres qui seraient des types primitifs au sein même de la liste d'initialisation ;)