Detruire une instance dans son constructeur

Bonjour,

J'ai une classe dans laquelle j'aimerais faire des initialisations diverses (ouverture de fichier, tests, etc). Dans le cas ou ces tests ne sont pas satisfaits, comment puis-je faire pour detruire l'objet dans son constructeur et/ou generer une exception retrouvable par try ... catch .

Enfin, si vous avez une solution plus simple... Sinon je pensais a un simple flag dans la classe qui serait a FALSE et que je devrais tester lors de la construction, et de faire un delete de l'objet au cas ou les tests ne sont pas concluants.

Mais je preferais utiliser une methode plus "clean" que cette histoire de flag.

Merci d'avance...

-g13

throw uneExceptionQuiIndiqueLaCauseDeLErreur

Et rapide avec ca 8-)

Avant de mettre ce topic "resolu", j'ai une derniere question: comment construire l'instance de ma classe sans passer par un "new" et gerer ces exceptions?

Code:

---

1 2 3 4

MaClasse Instance(..,..);   // ... et ensuite, comment gerer les exceptions??

---

au lieu de

Code:

---

1 2 3 4 5 6 7 8 9 10 11

MaClasse *Instance;   try { Instance = new MaClasse(..,..); } catch (int) { // Exception... }

---

Tu peux gerer ça avec une methode statique + un constructeur "protected" :

Code:

---

1 2 3 4 5 6 7 8

class MaClass { protected: MaClass();   public: static MaClass* construire(); }

---

Et :

Code:

---

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

MaClass* MaClass::construire() { MaClass* retour;   try { retour = new MaClasse(); } catch(...) { retour = NULL; }   return retour; }

---

Ainsi, il est impossible d'appeler le constructeur directement. Le seul moyen de construire une instance de MaClasse est d'appeller la méthode "construire" qui renvoit NULL si l'instance n'a pas pu être construite.

Merci pour la reponse, mais je me suis apparemment mal exprime: je demandais s'il etait possible de ne pas passer par un pointeur pour declarer mon instance...

Je reexplique: je voudrais pouvoir declarer:

Code:

---

MaClasse Instance(..,..);

---

et non

Code:

---

MaClasse *Instance = ...;

---

C'est juste pour une question de compatibilite avec mes precedentes version de la classe. Si les utilisateurs de cette classe doivent changer de la declaration sans pointeur a celle "avec", alors ils sont obliges de modifier la syntaxe:

Code:

---

Instance.Methode1(...)

---

a

Code:

---

Instance->Methode1(...)

---

Ce n'est pas tres tres grave (passqu'on n'est pas tres avance dans le projet), mais je voudrais savoir comment faire tant qu'a faire... :P

Tu peux toujours déclarer : MaClasse Instance(..,..);

Eventuellement avec un try/catch tout autour (ou le plus souvent, à un niveau plus haut dans la pile d'appels) pour gérer le cas à erreur.

Le probleme c'est que si je fais:

Code:

---

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

try { LogManager Test("C:\\MyLog.log",TRUE); printf("Success!\n"); } catch (int) { printf("Failure!\n"); return; }   Test.ToggleLogFileOutput(TRUE);

---

il me jette en disant que Test n'est pas defini... Ca voudrait dire que Test ne peut pas exister en dehors du bloc "try"

Oui, mais qu'est-ce qui t'empêche d'écrire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

try { LogManager Test("C:\\MyLog.log",true); printf("Success!\n"); Test.ToggleLogFileOutput(true); } catch (int) { printf("Failure!\n"); return; }

---

PS : true s'écrit true en C++, pas TRUE, qui n'est qu'un #define inutile sur certaines plateformes.

Re,

Ben comme j'ai dit precedemment, c'est seulement pour eviter a mes codeurs d'avoir a trop compliquer les changements dans leurs codes (deja ecrits pour certains), mais si y'a pas d'autres moyens, on fera comme ca.

Sinon pour le TRUE, c'est effectivement une redefinition.

Si le cas d'erreur est vraiment exceptionnel, et selon le type de gestion d'erreur demandé, rien ne t'empêche d'ajouter un simple try/catch dans le main pour sortir du programme proprement en indiquant le problème, sans rien changer au reste du code.

Bon OK... je crois qu'on va rester sur l'utilisation de pointeurs 8-)

Merci beaucoup!*

-Gorgo T.

*trop fort ce forum! :)

Sinon, tu peux aussi ecrire un "wrapper" de pointeur :

Code:

---

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

class Wrapper { private: MaClasse* p_pointeur;   public: Wrapper(); void setPointeur(MaClasse* pointeur);   public: void MaMethode_1(); void MaMethode_2(); .... }

---

Et :

Code:

---

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

Wrapper::Wrapper() { p_pointeur = NULL; }   Wrapper::setPointeur(MaClasse* pointeur) { p_pointeur = pointeur }   Wrapper::MaMethode_1() { if (p_pointeur) { return p_pointeur->MaMethode_1(); }   return CodeErreur; }

---

Comme ça, après tu utilises :

Code:

---

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

LogWrapper wrapper;   try { LogWrapper.setPointeur(new LogManager("C:\\MyLog.log",TRUE); printf("Success!\n"); } catch (int) { printf("Failure!\n"); return; }   wrapper.ToggleLogFileOutput(TRUE);

---

Mais bon, ça commence à devenir compliqué pour pas grand-chose....

Ok, merci pour le tuyau, je connaissais pas cette maniere de faire. On va aviser...

-GT

Sujet intéressant.
Il me rappelle deux conseils qu'on m'avait donné en son temps:
-en faire le moins possible dans les constructeurs (en prévoyant des méthodes d'initialisation);
-ne pas abuser des exceptions (voire les éviter).

En prenant exemple sur ton code

Code:

---

1 2 3 4 5 6 7 8

LogManager Test; if (Test.Init("C:\\MyLog.log",true)) { printf("Success!\n"); Test.ToggleLogFileOutput(true); } else printf("Failure!\n");

---

Citation:

---

Il me rappelle deux conseils qu'on m'avait donné en son temps:
-en faire le moins possible dans les constructeurs (en prévoyant des méthodes d'initialisation);
-ne pas abuser des exceptions (voire les éviter).

---

Deux très mauvais conseils.
Il y a une raison pourquoi une variable déclarée dans un try n'est visible que dans celui-ci. C'est pour garantir l'invariant que si la variable ne peut être construite, il n'est pas possible d'y accéder et ainsi de manipuler un objet qui est dans un état non défini.
Les constructeurs permettent de mettre en place des invariants, ce qui est beaucoup plus sûr.

En dehors du fait que les pointeurs, c'est le mal, ça permet plein d'opérations dangereuses, c'est une gestion des ressources manuelle et donc l'exception-safety n'est pas garantie, ça peut aussi avoir un certain nombre d'états invalides ou un état "vide".
Il est bien mieux de forcer à ce que tout objet soit initialisé avec des choses qui ont du sens à sa création, afin qu'il soit toujours dans un état utilisable.