AccueilCodesTutorielsForumsEmploiLivresGuide achatConnexion

  • CodeS-SourceS
  • RSS CodeS-SourceS
  • CodyxBot, le Bot GTalk & MSN qu'il vous faut !
  • Générez des revenus avec vos codes, scripts et tutoriaux
  • Aide à la navigation du site
begin process at 2009 07 12 09:48:28
Vous ne trouvez pas de réponse à votre problème ? Alors posez la question dans le forum. Souvenez-vous qu'il n'y a jamais de question bête, mais rester dans l'ignorance parce que l'on n'ose pas poser une question, ça c'est une erreur !

59 commentaire(s) de plus_plus_fab sur des sources sur tout CodeS-SourceS

Le : 04/01/2005 20:25:56
Source : SENDER BY SMTP [AVEC FICHIER JOINT]
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 ...


Le : 02/01/2005 12:46:07
Source : OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.
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.


Le : 29/12/2004 22:25:29
Source : OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.
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 ?

Le : 28/12/2004 20:35:28
Source : OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.
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 :)

@+

Le : 28/12/2004 18:56:05
Source : OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.
"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 ...


Le : 27/12/2004 22:39:51
Source : OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.
const ici aussi :
t_callback_const( const t_class& c ) : _callback_class( c )   {}

Le : 27/12/2004 22:37:40
Source : OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.
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 ...

Le : 27/12/2004 18:15:54
Source : OPTIMISATION DES CALLBACKS C++ RÉSOLUS À LA COMPILATION.
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.

Le : 11/12/2004 14:31:45
Source : CLASSE SSTRING OU LA MANIPULATION DES "STRING" PLUS INTUITIVE
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 !

Le : 11/12/2004 12:47:50
Source : CLASSE SSTRING OU LA MANIPULATION DES "STRING" PLUS INTUITIVE
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.


1 2 3 4 5 6


Nos sponsors

Sondage...

CalendriCode

Juillet 2009
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
2728293031  

Consulter la suite du CalendriCode

Appels d'offres

Comparez les prix Nouvelle version


iPod touch 2ème génération (8 Go)
Entre 210€ et 229€


Visiter le guide achat

Photothèque Nouveau !

Photo friends at the beach.Photo friends
Photo a pretty teenage girlPhoto pretty girl

Visiter la photothèque


Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés
Temps d'éxécution de la page : 0,296 sec

Google Coop CodeS-SourceS Google Coop CodeS-SourceS


Certaines images présentes sur le site (notament certains avatars) sont issues des collections IconShock, donc si vous souhaitez utiliser ces icons vous devez les acheter, ne les copiez pas et ne utilisez pas dans vos sites et applications sans les avoir commandé.