Discussion :

[r0d]

Bonjour à tous,

un petit problème de conception m'a amené à me poser la question suivante: Quelle sont les différences fondamentales entre le constructeur d'une classe et sa méthode Init()?

Ce qui engendre tout un tas de questions:
- Où doit-on faire l'allocation de mémoire pour les membres (tableaux, etc.)?
- Si l'on a des paramètres à passer pour construire et/ou initialiser sa classe, doit-on plutôt les passer au constructeur ou la la méthode Init()?
- Que doit-on mettre dans l'un et pas dans l'autre?

Merci.

[xxiemeciel]

Salut,

Personnellement je dirais que ca depend pas mal de ce que tu veux faire. Certaines classe peuvent avoir des membres dont elles n'ont pas la memoire a gerer, dans ce cas la destruction est laisser a celui qui l'a alloué.

Sinon la plupart du temps tu alloues ta memoire dans le constructeur et tu laliberes dans le destructeur.

Pour la methode init, elle est surtout utile lorsque le meme objet a besoin d'etre reutiliser plusieurs fois et que tu veux reinitialiser ton objet sans pour autant reallouer toute ta memoire. Ou tout simplement reinitialiser ton objet sans avoir a en instancier un nouveau.

XXiemeciel

[moldavi]

Salut.

J'ai toujours des difficultés de choix entre initialiser dans le constructeur ou avoit une méthode d'initialisation.

Lorsque tu utilises une méthode, tu as une valeur de retour que tu peux tester.
Pour le constructeur, tu peux passer en paramètre une référence qui pourra faire office de valeur de retour et qui te permettra de savoir si ton objet est bien construit.

Le problème est là, un objet peut ne pas être entièrement construit si une exception se produit. Tu peux alors te retrouver avec des fuites de mémoire, voir même un plantage, selon ta gestion d'erreurs.

Personnellement, je choisi la sécurité et dans le constructeur, je fais des initialisations simples et sans risques (pointeur à NULL, assignation de valeur pour les types courants, etc...).

Dans le livre "le langage C++", on te parle de ce problème, mais on ne te donne pas vraiment de solution. Tu as le choix, mais tu es prévenu.

[JolyLoic]

Le constructeur est une fonction spéciale appelée automatiquement à certains endroits, une fonction init n'est aucune sémantique spéciale, l'utilisateur doit l'appeler manuellement (risque d'oubli).

En règle générale, je dirais qu'il faut utiliser uniquement un constructeur. Dans certains cas, on n'a pas assez d'infos à la construction de l'objet pour tout initialiser, d'où une fonction init, mais c'est assez rare.

Pour signaler une erreur dans le constructeur, il peut lancer une exception, et dans ce cas, l'objet n'est pas construit du tout.

S'il est bien programmé, cette tentative de construction n'aura pas alloué de resosurces sans les libérer. Sinon, ça peut poser des problèmes. Mais écrire un constructeur correctement vis à vis des exceptions est du même niveau de difficulté que d'écrire une fonction init correctement vis à vis des exceptions.

[Luc Hermitte]

+1 à la réponse de Loïc.
Je vois les fonctions init() comme un archaisme utilisé par certains qui tiennent à les présenter avant les constructeurs, et une nécessité dans les extrêmes rares cas où l'on a besoin de post-construction polymorphique -- si je puis dire.
Mais là, mieux vaut, AMA, les encapsuler dans une fonction type factory qui se charge de la construction et de la post-construction.

Dans 99% des cas je fais tout dans le constructeur, voire je fusionne le résidu init() dans le constructeur principal des classes qu'il m'arrive de refactorer. C'est idiot, mais cela évite les fuites propres à

Code :

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

1
2
3
T * t = new T();
t->init(); // peut lever une exception, parce que la clé de connection n'est pas valide...
return t;

(oui, les auto_ptr<> sont parfaitement adaptés ici, et correspondent au second patch que j'applique à ce genre de code)

[r0d]

Merci pour vos réponses,

il semblerait donc que ma fonction Init() soit superflue. Il se trouve cependant que je n'ai pas le choix, elle fait partie du cahier des charges, et du coup, je suis bien obligé de mettre quelque chose dedans...

[...] et une nécessité dans les extrêmes rares cas où l'on a besoin de post-construction polymorphique -- si je puis dire.

je ne comprends pas, pourrais-tu m'expliquer un peu ce que tu veux dire s'il te plait? Qu'est-ce qu'une post-construction polymorphique?

Mais là, mieux vaut, AMA, les encapsuler dans une fonction type factory qui se charge de la construction et de la post-construction.

Ok pour l'encapsulation dans une fonction de type factory. Mais qu'est-ce que AMA?

[...] cela évite les fuites propres à

Code :

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

1
2
3
T * t = new T();
t->init(); // peut lever une exception, parce que la clé de connection n'est pas valide...
return t;

(oui, les auto_ptr<> sont parfaitement adaptés ici, et correspondent au second patch que j'applique à ce genre de code)

Je ne comprends pas ce que tu veux montrer ici Pourrais-tu me donner quelques explications s'il te plait?

S'il est bien programmé, cette tentative de construction n'aura pas alloué de resosurces sans les libérer.

Si j'ai bien compris, si on a une construction du type:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
MaClasse::MaClasse(int iValue)
{
   m_aiMonTableau = new int(iValue);
   try
   {
      m_pMonObjet->Connect(); // connection à une bdd par exemple
   }
 
   catch (CMyConnectionException* pEx)
   {
      pEx->ReportError();
   }
}

On risque d'allouer le tableau m_aiMonTableau alors que la classe n'est pas construite? (dans le cas où le connect() renvoie une exception)
Il faudrait alors rajouter un delete[] m_aiMonTableau; dans le catch. C'est ça?


Encore merci

[JolyLoic]

[...] et une nécessité dans les extrêmes rares cas où l'on a besoin de post-construction polymorphique -- si je puis dire.

je ne comprends pas, pourrais-tu m'expliquer un peu ce que tu veux dire s'il te plait? Qu'est-ce qu'une post-construction polymorphique?

Un constructeur ne peut pas être polymorphe, ni appeler une fonction de sa classe de manière polymorphe. Exemple : La classe de base Figue a une fonction draw virtuelle pure. On veut dans le constructeur de chaque figure l'afficher. On ne peut pas directement. On doit alors demander à l'utilisateur d'appeler lui même la fonction draw après la cration. Il s'agit d'une étape post construction, qui est polymorphique.

Mais là, mieux vaut, AMA, les encapsuler dans une fonction type factory qui se charge de la construction et de la post-construction.

Ok pour l'encapsulation dans une fonction de type factory. Mais qu'est-ce que AMA?

AMA = A mon avis.

[...] cela évite les fuites propres à

Code :

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

1
2
3
T * t = new T();
t->init(); // peut lever une exception, parce que la clé de connection n'est pas valide...
return t;

(oui, les auto_ptr<> sont parfaitement adaptés ici, et correspondent au second patch que j'applique à ce genre de code)

Je ne comprends pas ce que tu veux montrer ici Pourrais-tu me donner quelques explications s'il te plait?

Si init lève une exception, la mémoire (ou autres ressources) allouée pour t n'est jamais libérée.

S'il est bien programmé, cette tentative de construction n'aura pas alloué de resosurces sans les libérer.

Si j'ai bien compris, si on a une construction du type:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
MaClasse::MaClasse(int iValue)
{
   m_aiMonTableau = new int(iValue);
   try
   {
      m_pMonObjet->Connect(); // connection à une bdd par exemple
   }
 
   catch (CMyConnectionException* pEx)
   {
      pEx->ReportError();
   }
}

On risque d'allouer le tableau m_aiMonTableau alors que la classe n'est pas construite? (dans le cas où le connect() renvoie une exception)
Il faudrait alors rajouter un delete[] m_aiMonTableau; dans le catch. C'est ça?

Oui et non. Oui le problème est bien celui là. Non, sa résolution ne passe pas par un bloc catch, mais plutôt par du RAII : Par exemple, ici, au lieu d'utiliser un int* pour le tableau, utiliser un vector<int>.

[r0d]

Merci pour ces précisions
Mais j'ai encore une question...

AMA = A mon avis.

Oui et non. Oui le problème est bien celui là. Non, sa résolution ne passe pas par un bloc catch, mais plutôt par du RAII : Par exemple, ici, au lieu d'utiliser un int* pour le tableau, utiliser un vector<int>.

Qu'est-ce que le RAII? Et comment le vector se débrouille-t-il pour s'auto-effacer en cas de problème dans le constructeur? Utilise-t-il un Observer?

[Laurent Gomila]

Le RAII : http://c.developpez.com/faq/cpp/?pag...POINTEURS_raii

Après avoir lu ça, tu devrais pouvoir répondre tout seul à ta question sur le vector.

[r0d]

Ok merci.

Cet article est vraiment excellent. Il m'a permi de comprendre l'utilité des smart pointers, en plus du RAII que je ne connaissais pas. Un idiome puissant et simple finalement. D'ailleurs, pourquoi n'est-ce pas un design pattern?

[Luc Hermitte]

Idiome et design pattern sont deux choses proches arrivées à peu près au même moment (je parle d'histoire) et ayant donc ... des noms différents.
Aujourdh'ui, on retient (moi du moins) en général qu'un idiome est un petit DP spécialisé pour un langage. Je trouve aussi qu'en C++, on parle plus volontier d'idiomes que de patterns pour des choses comme le RAII, l'enveloppe-lettre, ...

Quant au RAII, son équivalent dans d'autres langages que je ne citerai pas, est le dispose-pattern ... (Ils s'inscrivent tout deux dans le cadre plus général de la libération déterministe de ressources)

[r0d]

merci à tous, j'ai appris beaucoup grâce à vous. Et bien que j'aie encore tout un tas de questions concernant la conception, je vais clore ce topic et continuer mon investigation tranquillement. Et puis je vais me remettre à l'UML, que je n'ai plus pratiqué depuis l'université