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�