Discussion :

[buzzz]

je bosse avec c++builder et je vois que ces deux systemes sont
possibles, je comprends mal la difference

J'ai vu pas mal d'exemples sur les threads qui utilisent toujours
__try __finally
normalement c'est equivalent a un try catch(...)

et une derniere question
comment recupere t on l'exception (eventuellement pour la relancer) avec

Code :

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

1
2
3
4
5
catch(...)
{
  do...
  throw ??
}

[dvsoft]

bonjour

Aller un petit effort.
saisie __finaly et tape sur F1 pour avoir de l'aide

Rubrique:Blocs de terminaison

Alain

[JolyLoic]

__finally n'est pas du C++, mais une truc spécifique à un compilo.

Pour relancer une exception dans un bloc catch, il suffit de faire throw; dedans.

[buzzz]

resultat de F1 :

Syntaxe

__finally {instruction-composée}

Description

Le mot clé __finally spécifie les actions qui doivent être entreprises quel que soit l'existence du flux dans le __try précédent.

il me semble comprendre qu'il y a une difference fondamentale etant donné que finally est toujours executé contrairement au bloc catch

Pour relancer une exception dans un bloc catch, il suffit de faire throw; dedans

ok merci

voila mon probleme :

Code :

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

1
2
3
4
5
6
7
8
9
A * new A();
__try
{
  A->toto();
}
__finally
{
  delete A;
}

donc ici la gestion du delete est simplifié, parfait
cependant avec un couple try/catch je ne vois pas trop
comment faire a part dupliquer le code dans un catch
et apres le catch :

Code :

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

1
2
3
4
5
6
7
8
9
 try
{
  A->toto();
}
catch(...)
{
  delete A;
}
delete A;

[JolyLoic]

La réponse est RAII (tiens, je n'ai rien vu dans la FAQ à ce sujet...) :

A chaque fois qu'une gestion de ressource (mémoire, mutex,...) fait appel à deux fonction, l'une pour l'acquérir (par exemple new), l'autre pour la libérer (par exemple delete), il ne faut pas écrire :

Code :

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

1
2
3
4
5
6
int f()
{
  maRessource.acquiert();
  // On fait des choses
  maRessource.libere();
}

Car si pendant les "choses", une exception est lancée, un return est appelé... la ressource ne sera jamais libérée.

La solution est alors de créer une classe ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
struct RessourceHolder
{
  RessourceHolder(Ressource &r) : ressourceHeld(r)
  {
    ressourceHeld.acquiert();
  }
  ~RessourceHolder() {ressourceHeld.libere();}
  Ressource &ressourceHeld;
};

Et de réécrire le code ainsi :

Code :

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

1
2
3
4
5
6
int f()
{
  RessourceHolder(maRessource);
  // On fait des choses
  // Et le compilateur fait le boulot de libération à notre place.
}

Une classe de type RessourceHolder pour des pointeurs existe déjà, et est en standard de fait. Regarde boost::scoped_ptr sur www.boost.org.

[buzzz]

oui ok merci

on m'a deje vendu de la RAII sur un autre post different
effectivement cela supprime les problemes

sinon ? depuis quand parle t on de cette RAII
et y a t il un bouquin qui discute ce genre de chose
(meme en anglais) histoire d'etre up to date

[JolyLoic]

Exceptional C++ de Sutter, mais comme c'est tiré des Guru of the Week, tu dois pouvoir en lire une bonne partie sur http://www.gotw.ca/gotw/index.htm