OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.

Messages postés
11
Date d'inscription
mercredi 25 décembre 2002
Statut
Membre
Dernière intervention
29 décembre 2004
-
Messages postés
371
Date d'inscription
dimanche 4 janvier 2004
Statut
Membre
Dernière intervention
23 septembre 2009
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/28416-optimisation-des-callbacks-c-resolus-a-la-compilation

Messages postés
371
Date d'inscription
dimanche 4 janvier 2004
Statut
Membre
Dernière intervention
23 septembre 2009

J'ai qd même ajouter une fonction membre "without_throw" avec un return par défaut qui effectivement ,'a que peu de sens.

Merci encore pour ton aide.
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

salut,

effectivement V1 n'apporte rien, et le pire (je me confesse), c'est que je n'en étais pas conscient !
La version 2 souffre d'un gros défaut : on ne peut pas appeler what() si l'exception ne dérive pas de std::exception. On perd donc le message d'erreur. De plus, si la classe d'exception possede d'autres informations accessibles avec d'autres méthodes que what(), c'est perdu aussi (qu'elle dérive de std::exception ou non). A abandonner donc.
Pour la version 3, ça me parait difficile de retourner qqchose de cohérent ... (il n'y a pas de return)
Finalement, je pense que ton code est bon tel qu'il est.
Messages postés
371
Date d'inscription
dimanche 4 janvier 2004
Statut
Membre
Dernière intervention
23 septembre 2009

Dans la V1, le try/catch n'apporte rien par rapport à l'original. La V2 peut effectivement répondre à un besoin spécifique : masquer toutes les exceptions (std ou pas).

Je proposerait égallement une V3 "bete&mechante" :
inline t_return call_wo_throw( t_argument parameter ) throw ()
{
try
{
return ( _class_instance->*_method )( parameter );
}
catch(...)
{
// rien
}
}
Messages postés
232
Date d'inscription
vendredi 9 janvier 2004
Statut
Membre
Dernière intervention
8 janvier 2005

effectivement, ça devient pas mal je trouve ...
Je te propose 2 solutions pour propager les exceptions :

// v1 :
inline t_return call( t_argument parameter )
{
if( _class_instance == 0 )
throw bad_instance();
if( _method == 0 )
throw bad_method();
t_return tr;
try {
tr = ( _class_instance->*_method )( parameter );
}
catch(...)
{
throw; // l'appelant se débrouille
}
return tr;
}

// v2 :
on est sur que cette méthode ne déclenchera pas d'autres exceptions.
personellement, je ne définirais pas les classes d'exceptions à l'intérieur
des classes de call_back. Par contre, je les emballerai dans le meme
espace de nommage.
cette solution amene naturellemnt à faire hériter bad_instance, bad_method, bad_call_unexpected et bad_call, de bad_callback (par exemple), lui meme héritant de std::exception (comme c'est le cas).

inline t_return call( t_argument parameter ) throw (bad_instance, bad_method, bad_call, bad_call_unexpected)
{
if( _class_instance == 0 )
throw bad_instance();
if( _method == 0 )
throw bad_method();
t_return tr;
try {
tr = ( _class_instance->*_method )( parameter );
}
catch(const std::exception& e) // eventuellement !
{
throw bad_call(e.what());
}
catch(...)
{
throw bad_call_unexpected();
}
return tr;
}

Je n'ai pas de préférences :/, qu'en penses-tu ?
Messages postés
371
Date d'inscription
dimanche 4 janvier 2004
Statut
Membre
Dernière intervention
23 septembre 2009

Bonjour,

L'ecriture des classes callback reste perfectible. Mais cela prend une tournure intéressante ! Merci pour tes conseils. ^_^

Cordialement,
X.
Afficher les 17 commentaires