ton SMTP, c'est le Sado Maso Transfer Protocol ?
Sérieux, la c'est le pompon.
code les chaines en dur, et utilise les pointeurs pour éviter les copies. Concatène quand y a besoin.
D'habitude les codes comme ça ne m'empeche pas de dormir, mais la je crois que je vais mettre une sangle pour éviter les sursauts ...

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.

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 ?

Salut,

pour les exceptions, je songe à une autre conception, faire 2 méthodes dans les t_callback*, une qui n'utilise pas les exceptions (operator()(...)), l'autre qui déclencherai des exceptions, et qui propagerai les exceptions pouvant intervenir dans la fonction appelée. C'est juste une idée ...

"A charge du developpeur soit de completer le throw par une exception standard ou de son cru"
Pourquoi pas une classe d' exception "de son cru" dérivant des exceptions standard ?

"L'appelle d'une fonction (par son pointeur) compte pour 90% dans le temps d'execution du test de callback dynamique."
Je pense qu'un bon optimiseur doit pouvoir éliminer ce code d'erreur, tout est facilement prévisible à la compilation ... Par contre, je ne suis pas sur de la résolution inline de la fonction appelée par l'intermédiaire d'un pointeur de fonction.

Avec ton main, il est intéressant de constater la différence de rapidité d'exécution entre la version const et la version non const (si on compile sans optimisations).

Sinon, ça fait plaisir de voir un programmeur sous w$ évoluant du coté clair :)

@+

"Toutes mes excuses pour cet oubli impardonnable !"
Vous etes pardonné mon cher mais que ça ne se renouvelle pas :)

Cette ligne me parait bizarre ...
redéclenchement de quelle exception ?
if( _class_instance == 0 && _method == 0 ) throw;
il vaudrait mieux déclencher une exception, voire séparer les tests et en déclencher une différente suivant le cas. Ou bien enlever la méthode set et oter les parametres optionels dans le constructeur ? ça restreint un peu son utilisation d'accord ...

const ici aussi :
t_callback_const( const t_class& c ) : _callback_class( c )   {}

mouais, il manque 2 const :

template<
typename t_class,
typename t_return,
typename t_argument,
t_return ( t_class::*fm )( t_argument ) const
>
struct t_callback_const
{
    t_callback_const( t_class& c ) : _callback_class( c )   {}
    inline t_return operator()( t_argument arg )const
    {
        return (_callback_class.*fm)( arg );
    }
private:
    const t_class& _callback_class;
};

pour les exceptions, tu veux pouvoir gérer une méthode genre :
void A::f(void)throw(std::bad_alloc) ? mis à part un catch(...) throw, je ne vois pas comment faire mieux.

"Je suis un peu étonné de ta dernière remarque. Peux-tu préciser ? Ca m'intéresse."
Désolé, rien d'intéressant, juste pour dire que j'ai déjà vu d'horribles programme s(inspiré des pointeurs de fonctions en C) qui utilisaient abusivement les pointeurs de fonctions membres, en détriment d'une conception objet cohérente.  De la à la violer ? Je suis en train d'y réfléchir ...

salut,

Tu attends surement qu'on te pose la question : et la "constness" ?
alors, je te la pose :)

Mise à part que les fonctions membres des exemples doivent etre déclarées const, aucune remarque sur le code, j'aime bien.
Mais je considère les procédés de ce genre comme des hacks à n'utiliser que dans des cas bien spécifiques.

il y a une fuite memoire quand tu ne libere pas les objets que tu alloues.
char* p = new char[50];
p = new char[30];
la, tu as perdu 50 octets, ils ne sont en effet plus référencé et il n'est plus possible de les liberer.

char* p = new char[50];
delete [] p;
p = new char[30];
la, c'est bon.

delete[] dans le destructeur aussi !

while(*b)
    {
        b++;
        len_b++;
    }
au lieu de faire ça, tu peux faire len_b = strlen(b);

tes typedef, ils polluent quand meme bien l'espace de nom global !

Salut,

il manque le copy constructeur.
pour prendre la taille d'une chaine de caractere : strlen() de <cstring> (<string.h>), pour copier strcpy.
les operateurs +, +=, =, provoque des fuites memoires abominables ! Il faut faire un delete avant de réallouer !
et les typedef sstring, Sstring, ... c'est pas tres utile amha.