Constructeurs & constructeur par défaut

Bonjour,
Je commence à étudier le cpp et j'ai appris qu'il était possible de définir des valeurs par défaut pour des paramètres envoyé au constructeur
J'ai voulu fusionner mes 2 constructeurs
L'un avec paramètres et l'autre sans paramètres
Seulement le compilateur boude un peu pourquoi?

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

/* Panneau::Panneau() { if(DEBUG) cout << "appel constructeur defaut: " << endl; nom = NULL; setX(0); setY(0); setLargeur(0); setHauteur(0); }   Panneau::Panneau(const char *nom, int x, int y, int l, int h) { */   Panneau::Panneau(const char *nom = NULL, int x = 0, int y = 0, int l = 0, int h = 0) { if(DEBUG) cout << "appel constructeur avec Parametres: " << endl; this->nom = NULL; setNom(nom); setX(x); setY(y); setLargeur(l); setHauteur(h); }

---

- il faudrait au moins indiquer les erreurs remontées par le compilateur
- si tous les paramètres ont une valeur par défaut, comment le compilateur est-il sencé savoir s'il doit appeler le constructeur par défaut ou celui avec tous les paramètres ayant une valeur par défaut ?
- les valeurs par défaut se mettent dans le prototype uniquement, pas dans l'implémentation

bien justement il n'y a plus de constructeur par défaut c'est le constructeur avc paramètres qui initialises les éléments

l'idée étant que si l'on appel sans aucun parametre il initialise les "variables" de l'objet sinon si il y en a il mets les valeurs passées en parametre

voici l'erreur
http://prntscr.com/lcco90

Salut,
Pourrait-on commencer par voir comment les constructeurs sont déclarés au sein de ta fonction (donc, dans le fichier d'en-tête) :question:

Car, a priori, les valeurs par défaut ne doivent être fournie qu'au niveau de la déclaration le la fonction, à moins -- bien sur -- que l'implémentation "fasse office" de déclaration.

Le code doit donc ressembler à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9

//dans le fichier d'en-tête class Truc{ public: Truc(Type1 param1 = val1, Type2 param2 = val2 /*, ...); }; // dans le fichier d'implémentation Truc::Truc(Type1 param1 , Type2 param2 /*, ...){   /*...**/ }

---

Ensuite, il faut savoir qu'il faut être très prudent lorsque l'on envisage de fournir des valeurs par défaut pour les paramètres de fonction, pour plusieurs raisons:

La première est que si tu prévois une fonction qui prend cinq paramètres (comme ton constructeur paramétré) et que tu fournis une valeur par défaut pour chacun de ces paramètres, tu autorise le compilateur à utiliser cette même déclaration de SIX manières différentes:

1. En ne fournissant aucun argument lors de l'appel (les cinq valeurs par défaut sont alors utilisées)
2. en fournissant un argument uniquement pour le premier paramètre (char *). Les valeurs par défaut pour les quatre autres seront alors utilisées
3. en fournissant un argument pour le premier et pour le deuxième paramètre (un char *, int). Les valeurs par défaut seront alors utilisées pour les trois derniers paramètres
4. en fournissant un argument pour les trois premiers paramètres (un char* , int , int). Les valeurs par défaut seront alors utilisées pour les deux derniers paramètres
5. en fournissant un argument pour les quatre premiers paramètres (char *, int, int, int) . la valeur par défaut sera utilisée pour le dernier paramètres
6. en fournissant un argument pour les cinq paramètres. Aucune valeur par défaut ne sera alors utilisée

Mais, s'il n'y a qu'une de ces possibilités qui correspond à une possibilité fournie "par ailleurs" (mettons que tu aies aussi un Paneau(char * , int ) qui traine quelque part) cela créera un conflit que le compilateur ne supportera pas.

En effet, lorsque tu ferais appel (pour suivre mon exemple) au constructeur sous la forme de Panneau p{"Salut", 15}; le compilateur ne pourrait pas savoir s'il doit faire appel à la version qui ne demande qu'un char * et un int ou s'il doit faire appel à la version qui prend cinq paramètres pour lesquelles il existe des valeurs par défaut (dont trois seraient utilisées).

Je subodore très fortement que c'est ce qui se sera passé ici, et que tu as un conflit entre le constructeur qui n'attend aucun paramètre et celui qui attend cinq paramètres pour lesquels il a été donné cinq valeurs par défaut ;)

Enfin, il y a tout le problème qui consiste à rester cohérent quant à la manière dont nous permettront de créer une instance de notre classe.

Ma boule de crystal me dit que tu veux travailler sur deux fois deux données qui "vont bien ensembles", et que tu as, d'un coté une notion de position dans un référentiel à deux positions (x, y) et, de l'autre, une notion de surfrace / de périmètre /similaire (longueur et largeur). Et ca, ca me pose quelques problèmes philosophiques :

A l'extrême limite, je pourrais concevoir que l'on puisse définir une position "par défaut" comme étant à l'intersection des deux axes (0,0). Mais!!!!

Il n'y a -- à mon sens du moins -- aucune raison de permettre à "quelqu'un" de ne définir que la position sur l'axe des X ou que la position sur l'axe des Y (en considérant -- cela va de soit -- que la position "sur l'autre axe" est égale à 0)

Pire encore! Il me semble particulièrement difficile de justifier le fait que "quelque chose" qui soit sensé avoir une longueur et une largeur puisse avoir ... une longueur ou une largeur nulle (et plus encore d'imaginer que quelque chose puisse avoir une longueur ET une largeur nulle).

Si bien que sur les six possibilités que t'offrent l'utilisation des valeurs par défaut dans le cas présent, il y en a trois (soit la moitié !!!) qui n'ont aucune justification conceptuelle! Et ca, c'est particulièrement dangereux :P

En effet, le but du constructeur est -- typiquement -- de permettre au développeur de disposer, lorsqu'il décide de créer une instance de la classe, d'une variable cohérente directement "prête à l'emploi": une fois qu'il a créé la variable en question, il doit pouvoir la manipuler à sa guise, sans avoir à commencer à réfléchir à la procédure qu'il devrait mettre en place pour rendre cette donnée "cohérente".

Car la loi de l'emmerdement maximum plane en permanence au dessus de ta tête comme l'épée de la justice : si tu laisses la possibilité à celui qui utilise ta classe (ce sera peut-être toi même) de faire une connerie -- par exemple, en espérant qu'il suivra une procédure bien précise afin d'obtenir une donnée cohérente et prête à l'emploi -- tu dois t'attendre à ce qu'il "oublie" l'une ou l'autre étape de cette procédure.

Ne perds pas ton temps à te demander SI il fera la connerie... Car tu peux avoir la certitude qu'il la fera forcément un jour ou l'autre. Poses toi directement la question de savoir QUAND il la fera.

Manque de bol, la réponse sera toujours la même : au pire moment qui soit!

C'est d'ailleurs la raison pour laquelle tu va me faire le plaisir de virer ces fonctions setXXX qui semble parsemer ta classe comme des épis un champs de blé!

Car, si c'est pour t'amuser à fournir des accesseurs ( getXXX) et des mutateurs (setXXX) pour chacune de tes données, autant placer directement ces données dans l'accessibilité publique : cela t'évitera bien du soucis ;)

Les accesseurs peuvent éventuellement avoir une justification, car il se peut (mais cela reste encore à prouver) qu'il fassent partie des services que tu es en droit d'attendre de la part de ta classe. Mais il est temps de rappeler l'un des conseils primordiaux de Scott Meyers:

Citation:

---

Make interfaces easy to use correctly and hard to use incorrectly
(rendez vos interfaces faciles à utiliser de manière correcte et difficiles à utiliser de manière incorrecte)

---

Or, les données qui composent ta classe sont ce qui s'appelle des détails d'implémentation : elles n'ont qu'une seule et unique raison d'être qui est ... de permettre aux fonctions exposées par ta classe (autrement dit : aux services que ta classe propose) de travailler correctement.

Et, il se fait que ces données sont sans doute soumises à des règles strictes pour que ton plateau reste "cohérent" et "utilisable". Par exemple, j'ai émis de très gros doute quant au fait qu'un plateau présentant une longueur ET / OU une largeur nulle ait le moindre intérêt.

Et, encore une fois, si tu laisses à l'utilisateur de ta classe l'occasion de faire une connerie, tu dois t'attendre à ce qu'il la fasse tôt ou tard. Tu auras beau écrire en lettre de feu que la longueur et que la largeur ne peuvent pas être nulles, si tu laisses à l'utilisateur de ta classe le soin de calculer la longueur ou la largeur, tu dois t'attendre à ce que, tôt ou tard, il en vienne à décider de fournir une longueur ou une largeur nulle :P

Cela ne peut arriver en aucun cas!!!!

En outre, Je serais surpris que, une fois que les dimensions d'un panneau ont été définies, nous décidions "subitement" de les modifier. Nous pourrions sans doute décider de déplacer le panneau (au travers d'une fonction move(diffX, diffY) par exemple), mais décider de le redimensionner... Ca me semble quelque peu compromis :P Surtout si c'est pour le rallonger ou l'élargir ;)

Donc en outre si je comprends bien ne pas utiliser de valeur par défaut dans les constructeurs et il faut éviter le plus possible de mettre des valeurs par défaut dans les méthodes?
Ici j'avais pris la class panneau en exemple merci d'ailler de la réflexion de la taille j'en prends bonne note :mouarf:
J'avais pris ici ma class panneau pour faire des test vu qu'elle était déjà opperationnel comme ça j'avais déjà une base construite (gain de temps pour le test)

concernant les getter et setter c'est dans le cadre d'un projet de cours qu'il nous a été demandé de faire cela
Merci en tout cas pour votre aide à tout les 2

Citation:

---

Envoyé par Sparky95

Donc en outre si je comprends bien ne pas utiliser de valeur par défaut dans les constructeurs et il faut éviter le plus possible de mettre des valeurs par défaut dans les méthodes?

---

Non, c'est beaucoup plus subtile que cela à vrai dire :

Je ne vois absolument aucune objection majeure au fait d'utiliser des valeurs par défaut, que ce soit dans un constructeur ou dans une fonction.

La seule chose, c'est qu'il s'agit d'une possibilité avancée, qui a son lot d'avantages, mais qui a aussi son lot d'inconvénients.

Il s'agit donc d'être particulièrement prudent lorsque l'on envisage de fournir une valeur par défaut, avant de prendre la décision finale, en s'assurant que toutes les possibilités que cela peut ouvrir soient ... cohérentes par rapport à tes besoins spécifiques.

Et, si tu estimes qu'il est "cohérent" de fournir une valeur par défaut, il faut encore t'assurer que la valeur en question soit elle-même cohérente, car il s'agira d'une valeur choisie de manière arbitraire

Si tu te dis, par exemple, qu'une largeur par défaut de 15 cm est "cohérente" pour n'importe quel panneau, quelle que puisse en être la longueur peut avoir une largeur de 15cm (à moins que l'on n'indique explicitement une largeur différente), ca me va très bien! Et cela m'irait tout aussi bien si tu envisageais plutôt de fixer cette valeur par défaut à 30, à 45 ou à ... 156 cm :D

Du moins, tant que je peux me permettre d'ignorer l'usage auquel le tableau sera destiné :P

La seule chose, c'est que cette valeur par défaut de 15, 30, 45 ou 156 cm a un coté "arbitraire" et sera donc "sujette à discussion" (du genre de "oui, mais pourquoi cette valeur en particulier et pas une autre :question:')

Il est donc toujours préférable d'être en mesure de défendre la raison pour laquelle tu as choisi cette valeur et pas une autre ;)

[TIP] A priori, si tu ne trouve aucun moyen de défendre le choix de la valeur par défaut (ou si n'importe quelle valeur semble "aussi bonne qu'une autre"), cela peut être un indice fort du fait qu'elle n'a pas lieu d'être ;)

Si ton objectif est d'implémenter un constructeur sans paramètre pour initialiser tes champs avec des valeurs par défaut, une façon simple est celle-ci :

Code:

---

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

class Foo { public: Foo() = default;   Foo(int a, int b, int c) { // bla bla }   private: int a = 0; int b = 0; int c = 0; };

---

Une autre solution si en fait tu n’initialises pas directement les champs est de faire ceci :

Code:

---

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

class Foo { public: Foo() : Foo(0, 0, 0) { }   Foo(int a, int b, int c) { // bla bla }   private: int a; int b; int c; };

---

Enfin, n'oublies pas que ton code ne permet d'initialiser ta classe soit avec 0 paramètre soit avec 3 paramètres, mais d'initialiser ta classe avec un nombre variable de paramètres entre 0 et 3 :

Code:

---

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

class Foo { public: Foo(int a = 0, int b = 0, int c = 0) { // bla bla }   private: int a; int b; int c; };   int main() { Foo f1; Foo f2{1}; Foo f3{1, 2}; Foo f4{1, 2, 3}; }

---

Comme le dit koala01, c'est peut-être pas ce que tu veux...

Citation:

---

Envoyé par Sparky95

Donc en outre si je comprends bien ne pas utiliser de valeur par défaut dans les constructeurs et il faut éviter le plus possible de mettre des valeurs par défaut dans les méthodes?

---

J'ai trouvé ça super cool quand j'ai découvert ça ! Je l'ai utilisé plusieurs fois pour voir.... et je l'ai regretté pour certaines d'entre elles. Le plus gros problème est la perte d'explicité. Quand tu vois deux appels à la même fonction, l'une avec des paramètres, l'autre sans, tu te demandes tout de suite : quelle est la valeur par défaut ? Il faut alors retrouver la déclaration (mais pas la définition si elle est séparée) pour le savoir. Et des fois, avec le temps, tu te dis que la valeur par défaut n'est en fait pas la meilleure valeur que tu aurais pu mettre...mais c'est trop tard ! Je n'ai pas banni pour autant les valeurs par défaut, mais je les utilise avec prudence. Mes dernières utilisations sont par exemple pour des fonctions receive() : tu peux donner un timeout en paramètre, si tu ne donnes rien c'est timeout infini (en gros, pas de paramètres = je reçois point barre).

Petite question supplémentaire
Un appel de constructeur par un autre est-ce possible?
Visiblement en java c'est possible en mettant this() =>référence

Par contre il est dit que ce n'est pas possible avec la version la plus rependue (donc standard) de C++

Citation:

---

Envoyé par Bktero

Code:

---

1 2 3 4 5 6 7 8 9

class Foo { public: Foo() : Foo(0, 0, 0) { }   Foo(int a, int b, int c) { // bla bla }

---

---

J'ai essayé cela

Code:

---

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

Panneau::Panneau() { setCouleur(Couleur::ARGENT); Panneau(NULL, 0, 0, 0, 0, col); }   Panneau::Panneau(const char *nom, int x, int y, int l, int h) { setCouleur(Couleur::ARGENT); Panneau(nom, x, y, l, h, col); }   Panneau::Panneau(const char *nom, int x, int y, int l, int h, Couleur col) { this->nom = NULL; setNom(nom); setX(x); setY(y); setLargeur(l); setHauteur(h); setCouleur(col); }

---

Mais mes résultats sont erronés

Du coup est-ce possible?

Le message que tu cites date de 2012. A l'époque, la version de C++ la plus répandue était la version 03 mais depuis, les versions 11 et 14 sont sans doute plus répandue. Et les 2 supportent l'appel d'un constructeur depuis un autre, mais pas n'importe comment : cela doit être fait dans la member initializer list, comme un appel à un constructeur de la classe parente. C'est ce que je fais dans mon code, mais ce n'est pas ce que tu fais toi ;) Tu dois faire l'appel avant l'accolade qui ouvre le corps de ton constructeur.

Comment puis-je faire cela exactement?

car je viens d'essayer ceci

Code:

---

1 2 3 4

Panneau::Panneau() { setCouleur(Couleur::ARGENT); Panneau(NULL, 0, 0, 0, 0, col){} }

---

ainsi que cela

Code:

---

1 2 3

Panneau::Panneau(): setCouleur(Couleur::ARGENT); Panneau(NULL, 0, 0, 0, 0, col){}

---

Mais dans les 2 cas le compilateur n'est pas content et je ne vois pas trop comment le faire.
car le soucis est que col est initialisé dans mon cas avant que le constructeur soit appelé. Je suppose que c'est du à cela que j'ai le soucis?

:faq: https://cpp.developpez.com/faq/cpp/?...-l-affectation