Discussion :

[r0d]

Bonjour à tous,

j'ai créé un certain nombre de classe ces derniers temps, et à chaque fois que je créé une nouvelle classe, je me pose la question:
"est-ce que je met tout un tas de paramètres dans le constructeur ou est-ce que je ne fais qu'un constructeur par défaut et je créé une méthode d'initialisation pour ma classe?"

Exemple: je fais ça

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
 
classe MaClasse
{
public:
  MaClasse(int val1, int val2, string leNom);
 
private:
  int m_valeur1,m_valeur2;
  string m_leNom;
}
 
MaClasse::MaClasse(int val1, int val2, string leNom)
{
  m_valeur1 = val1;
  m_valeur2 = val2;
  m_leNom = leNom;
}

ou ça?

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
 
classe MaClasse
{
public:
  MaClasse();
  void init(int val1, int val2, string leNom);
 
private:
  int m_valeur1,m_valeur2;
  string m_leNom;
}
 
MaClasse::MaClasse(){}
 
void MaClasse::init(int val1, int val2, string leNom)
{
  m_valeur1 = val1;
  m_valeur2 = val2;
  m_leNom = leNom;
}

Dans quel cas utiliser quelle méthode? Qu'en pensez-vous?

[bigboomshakala]

salut,

moi je ferais ça

Code :

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

1
2
3
4
5
6
7
8
9
...
public:
  MaClasse(int val1, int val2, string leNom);
...
 
  MaClasse::MaClasse(int val1 = 0, int val2 = 0, string leNom = "")
: m_valeur1(val1),  m_valeur2(val2),  m_leNom(leNom)
{
};

je pense que c'est plus efficace, il n'y a qu'un appel au constructeur.
(pour les valeurs par défaut tu mets ce que tu veux bien sur)

[tut]

je ne vois pas l'intérêt de ta méthode init() :
- le constructeur sert entre autre à initialiser les attributs;
- si tu veux modifier tes attributs après construction, crée des accesseurs.

enfin, il me semble que c'est comme ça que l'on fait...

[r0d]

moi je ferais ça

Code:
...
public:
MaClasse(int val1, int val2, string leNom);
...

MaClasse::MaClasse(int val1 = 0, int val2 = 0, string leNom = "")
: m_valeur1(val1), m_valeur2(val2), m_leNom(leNom)
{
};

Dans ce cas, est-ce que je peux déclarer un tableau de MaClasse comme ça:

Code :

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

1
2
3
4
5
Classe UneAutreClasse
{
...
MaClasse monTableau[10];
};

?

[bigboomshakala]

oui bien sur, dans ce cas les attributs des objets MaClasse du tableau prennent leur valeur par défaut

i.e. m_valeur1 = 0, m_valeur2 = 0 et m_leNom = ""

car le constructeur appelé est MaClasse(0,0,"") étant donné que tu ne passes pas de paramètres

[r0d]

Ok, et bien en effet, il n'y a aucun intérêt à faire un init.

Merci.

[Laurent Gomila]

Pour les problèmes de tableaux / constructeurs, ne pas oublier que std::vector permet d'avoir des tableaux de classes ne possédant pas de constructeur par défaut .

[r0d]

Ha!! J'ai trouvé un exemple où ça peut-être intéressant d'avoir un init():

J'ai deux classes MaClasse1 et MaClasse2. MaClasse2 est une agregation de MaClasse1, par exemple:

Code :

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

1
2
3
4
5
6
7
 
class MaClasse2
{
...
MaClasse1 monTableau[10];
...
}

Dans mon programme, j'ai:

Code :

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

1
2
3
4
5
6
7
 
MaClasse1 *p1 = new MaClasse1();
MaClasse2 c1; //ici, le tableau c1.MonTableau est alloué
for (int i=0; i<10; i++)
{
   c1.MonTableau[i].init(<mes paramètres>);
}

Dans ce cas, je ne peux pas mettre un new dans ma boucle! Qu'en pensez-vous?

[thewho]

Bonjour,

Dans ce cas, tu ne fais que remplir ton tableau avec des données, donc le nom de la fonction init n'est pas très bien choisi, à mon avis:
c'est un simple accesseur, donc un nom comme Setxxxx serait plus clair que init, qui pour moi implique des opérations autres que simplement mettre à jour des valeurs.

[Yabo]

Ok, et bien en effet, il n'y a aucun intérêt à faire un init.

Merci.

Moi j'en connais au moins un interêt. Si le code d'initialisation peut déclencher des exceptions.

En effet tu ne peux pas faire ca :

Code :

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

1
2
3
4
5
6
7
8
9
 
try
{
      MaClasse obj(...);
}
catch(...)
{
   // ...
}

Parce'que alors ta variable obj n'a pour portée que le bloc try{} ce qui est embêtant.
Alors que :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
MaClass obj;
try
{
     obj.init(...);
}
catch(...)
{
      // ...
}

Ca va mieux J'avais déjà posé la question ici et il s'avère qu'il n'y a pas de solution hormis celle-là.

[Luc Hermitte]

A quoi sert ton objet si tu n'as pas pu l'initialiser à l'état désiré ?

Sinon, de façon tordue, il y a :

Code :

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

1
2
3
4
5
6
7
ObjS o;
try { 
    ObjS o2("toto"); 
    o2.swap(o); // je ne sais plus si on peut faire ça en une ligne
 
    o = ObjS("titi");
}....

Concernant les tableaux, Loulou24 a donné la solution

Code :

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

1
2
3
4
5
6
7
8
9
10
struct ObjI {
    ObjI(int);
private:
    ObjI(); // constructeur par défaut interdit
    ....
};
...
std::vector<ObjI> v;
for (int i=0 ; i!=10 ; ++i)
    v.push_back( ObjI(i) );

[Yabo]

A quoi sert ton objet si tu n'as pas pu l'initialiser à l'état désiré ?

A rien mais il faut pouvoir gérer le cas où ca ne marche pas. Dans le premier cas même si ca réussi il est détruit à la fin du bloc .. c'est embêtant.

Sinon, de façon tordue, il y a :

Code :

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

1
2
3
4
5
6
7
ObjS o;
try { 
    ObjS o2("toto"); 
    o2.swap(o); // je ne sais plus si on peut faire ça en une ligne
 
    o = ObjS("titi");
}....

Je préfère ma fonction init(), plus clair à mon avis.

[Luc Hermitte]

Avec une construction normale, si ça foire, tu n'as pas d'objet créé et tu sors du bloc, sinon tu as un objet construit qui sera détruit à la fin du bloc.

Si l'objet ne sert à rien, pourquoi s'embéter à le vouloir ?

[Yabo]

Avec une construction normale, si ça foire, tu n'as pas d'objet créé et tu sors du bloc, sinon tu as un objet construit qui sera détruit à la fin du bloc.

Si l'objet ne sert à rien, pourquoi s'embéter à le vouloir ?

Oui mais j'ai pas spécialement envie de faire tout mon code lié à mon objet créé dans le bloc try{ }

[Luc Hermitte]

???

Autre question : es-tu sûr que tu traites l'erreur à l'endroit où elle doit l'être ? (la question cachée dans la question se résume à "profites-tu du RAII?")

[Yabo]

???

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
try
{
    maclass obj(...)
 
    // je dois mettre tout le code qui utilise obj ici
}
catch(...)
{
    // ...
}
 
// alors que je préfère le mettre ici en fait

Autre question : es-tu sûr que tu traites l'erreur à l'endroit où elle doit l'être ? (la question cachée dans la question se résume à "profites-tu du RAII?")

En fait on peut comparer avec les std::fstream. En effet lors qu'ouvre un fichier je dois faire ensuite un is_open() pour être sûr que ca a marché, (ou un if( !mon_fichier ) c'est pas là la question).
Moi au lieu je préfère lever une exception si la construction échoue et la récupérer pour la traiter.

Enfin moi je la trouve bien moi la fonction init() dans ce cas précis.

Et c'est bête parce'que l'on a déjà eu ce débat mais visiblement victime du délestage

[Laurent Gomila]

Ne serait-ce point celui-ci ? http://www.developpez.net/forums/viewtopic.php?t=220238

[Yabo]

Ne serait-ce point celui-ci ? http://www.developpez.net/forums/viewtopic.php?t=220238

Exact ! Je croiais avoir fait un poste à part entière et je ne cherchais donc que dans les titres de mes postes. Désolé

Donc oui c'était ce poste et la solution a été pour moi de faire une fonction init() et tout marche très bien

[JolyLoic]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
try
{
    maclass obj(...)
 
    // je dois mettre tout le code qui utilise obj ici
}
catch(...)
{
    // ...
}
 
// alors que je préfère le mettre ici en fait

Et cette préférence est-elle fondée sur quelque chose ?

Autre question : es-tu sûr que tu traites l'erreur à l'endroit où elle doit l'être ? (la question cachée dans la question se résume à "profites-tu du RAII?")

En fait on peut comparer avec les std::fstream. En effet lors qu'ouvre un fichier je dois faire ensuite un is_open() pour être sûr que ca a marché, (ou un if( !mon_fichier ) c'est pas là la question).
Moi au lieu je préfère lever une exception si la construction échoue et la récupérer pour la traiter.

Tu souhaite lever une exception, ok, pourquoi pas. Par contre, si tu as besoin de try/catch pour faire du ménage, alors là, je ne suis pas d'accord (et je rejoins Luc). Il a été montré que c'est impossible à gérer comme ça, et que le RAII est bien suppérieur. Pour moi, un try/catch ne doit apparaître que dans 4 situations :
- Quand on est capable de gérer l'erreur (affichage, redémarrage de l'appli...)
- Une fois par thread au plus haut niveau, pour les cas qu'on a pas géré, histoire d'essayer en désespoire de cause d'afficher un message à l'utilisateur
- Quand on sort du langage C++ (passage à du C, Fortran... qui ne supportent pas les exceptions)
- Quand on adapte une exception d'une bibliothèque pour en faire une exception d'un autre type (et donc avec un throw à la fin du catch).

Et c'est bête parce'que l'on a déjà eu ce débat mais visiblement victime du délestage

Mais j'étais pas là à l'époque, alors que maintenant, je peux jouer aussi...

[Yabo]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
try
{
    maclass obj(...)
 
    // je dois mettre tout le code qui utilise obj ici
}
catch(...)
{
    // ...
}
 
// alors que je préfère le mettre ici en fait

Et cette préférence est-elle fondée sur quelque chose ?

Ne pas imbriquer le code encore et encore. Luc m'avait déjà proposé cette solution :

Hum... Difficile de répondre de manière générale.
Si ton constructeur échoue, de toutes façons tu vas remonter et tu ne pourras pas continuer ta fonction. Il est des cas où l'on ne veut englober que le constructeur il vrai. Mais ne peux-tu pas tout simplement étendre ton try jusqu'à la fin de la fonction ? Quitte à faire un catch spécialisé sur les erreurs de construction de A.

Mais évidemment avec la classe A c'est envisageable mais la réalité est plus complexe.
Je viens de relire le code que j'avais fait à l'époque. Bon donc en gros ce qu'il me fallait c'était un objet qui ne soit pas un pointeur, qui ait une très grande portée dans le programme (c'était une classe pour gérer les fichiers de log donc j'ai besoin de l'objet un peu partout (rassurez-vous j'ai pas fais de variables globales )), et dont la contruction puisse être dans un bloc try{} catch(){}.

En relisant mon code ce que j'ai fait :

une fonction init() privée suceptible de lever une exception
une fonction begin() qui a la tête :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
void CLog::Begin(const char *FileName, bool Overwrite)
{
	try
	{
		Init(FileName, Overwrite);
	}
	catch(CLogErr &err)
	{
		err.debug();
		cerr << "Log level set to None" << endl;
		SetLevel(None);
	}
}

Et mon constructeur :

Code :

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

1
2
3
4
5
 
CLog::CLog(const char *FileName, bool Overwrite)
{
	Begin(FileName, Overwrite);
}

Donc en fait j'ai fait une fonction d'init mais pas dans le sens que j'ai évoqué précédemment. Ca date de juillet quand même ce débat depuis le temps hein ...

Mais j'étais pas là à l'époque, alors que maintenant, je peux jouer aussi... Coucou

Avec plaisir