Discussion :

[NLS le pingouin]

Bonjour à tous,
Je suis sur un projet qui prend de l'ampleur. Il me faut commencer à développer des outils de débugging. Je suis en train de travailler sur la conception d'une classe de type logger, et je me pose surtout des questions sur la manière de l'implanter dans mon code.
Cette classe devra tout bêtement recevoir des paramètres divers pour les afficher dans la console ou les enregistrer dans un unique fichier .log. Les informations qu'elles devra gérer serons surtout en rapport avec les différentes ressources chargées. Il s'agit d'un jeu 2D, les ressources serons principalement des fichiers de configuration, des images, des bibliothèques externes et des fichiers sonores.

Je ne sais pas vraiment si la meilleur solution serait de créer un objet globale de la classe logger pour l'utiliser tout le long du programme, ou plutôt de créer un objet logger dans chaque classe de mon programme.

Comment feriez-vous? Je n'ai pas vraiment plus de précision. C'est encore un peu confus dans ma tête. J'ai conscience qu'une classe globale est un peu une implantation à la sauvage, mais vu qu'elle ne gère qu'un seul fichier j'ai un peu de mal à voir ce que je pourrais gagner à créer plusieurs instances de cette classe (méthode plus propre mis part).

Merci de votre aide.

[Dr Dédé]

J'ai vu deux ou trois loggers dans des projets d'ampleur moyenne et il s'agissait toujours d'une classe avec une méthode statique Log() (ou un Singleton) et quelques overloads pour supporter différents "niveaux" de sévérité d'erreur. Si le programme est multi-threadé, il faut penser à protéger le stream derrière un mutex, mais à part je ne vois pas pourquoi on ferait plus complexe.

[koala01]

Salut,

Un logger est, classiquement, le genre de ressource que l'on a très facilement tendance à rendre globale, voire pour laquelle on s'organise afin de pouvoir la désactiver sur simple demande (par exemple en fournissant un define quelconque à la compilation).

Le pattern singleton est particulièrement adapté aux classes de logging, et, s'il ne devait servir qu'à une seule chose, ce serait sans doute pour elles.

Tu pourrais donc créer une classe de base (template) singleton proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
template <typename T>
class TSingleton
{
    public:
        static T & instance()
        {
            static T inst;
            return inst;
        }
    protected:
        /* seules les classes dérivées ont accès au constructeur et au
         * destructeur
         */
        TSingleton(){}
        ~TSingleton(){}
    private:
         /* copie et affectation interdite (en attendant C++1x ) */
         TSingelton(TSingleton const &);
         TSingleton& operator=(TSingleton const &);
};

Tu remarquera que je ne lui donne pas de fonction "destroy" car il n'y a, à mon sens, aucune raison pour nous donner l'occasion de détruire le singleton une fois qu'il a été créé.

Il sera, de toutes manières, correctement détruit au moment où l'application sera quittée

Il est possible de diviser le logging en trois partie distinctes:

1. L'exécution d'une action
2. La survenue d'un événement (ex: clique de souris,...)
3. Le résultat de l'action ou de l'événement

Nous devrions donc retrouver ces trois possibilités dans l'interface de notre logger qui prendrait la forme de (logger "console")

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
#include <tsingleton.hpp> // pour la classe de base
#include <iostream> // pour std::cerr
/* on appelle cette technique le CRTP pour
 * Curriously Recuriing Template Pattern.
 *
 * On peut, en effet, être étonné du fait que l'on utilise une classe 
 * template avec une classe que l'on crée à peine, mais cela fonctionne
 * :D
 */
class ConsoleLogger : public TSingleton<ConsoleLogger>
{
    /* il faut rendre la classe de base amie de la classe logger 
     * de manière à lui donner l'accès au constructeur et au
     * destructeur
     */
    friend class TSingleton<ConsoleLogger>;
    public:
    /* les fonctions que l'on utilisera */
    /* logging du lancement d'une action */
    void logAction(std::string const & first, std::string const & second,
                 std::string const & file, int line)
    {
        std::cerr<<first<<second<<" in file "<<file<<" at line "<<line;
    }
    void logEvent(std::string const & first, std::string const & file, int line)
    {
        std::cerr<<"Event: "<<first<<" in file "<<file<<" at line "<<line;
    }
    void logResult(std::string const & res, std::string const & info)
    {
        std::cerr<<res<<std::endl;
        if(info!="")
            std::cerr<<info<<endl;
    }
    private:
        /* le constructeur et le destructeur sont privés et définis 
         * pour que seule la classe de base puisse les invoquer
         */
         ConsoleLogger(){}
         ~ConsoleLogger(){}
         /* le constructeur par copie et l'opérateur d'affectation sont
          * privés et non défini pour éviter toute duplication de l'objet
          * (en attendant C++1x)
          */
          ConsoleLogger(ConsoleLogger const &);
          ConsoleLogger & operator=(ConsoleLogger const &);
};

Mais cette classe ne sera pas facile à utiliser, car elle nécessiterait l'écriture d'un code proche de

Code :

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

1
2
3
4
5
ConsoleLogger::instance().logAction("lecture du fichier",thefile,__FILE__,__LINE);
if(myressource.read(thefile))
    ConsoleLogger::instance().logResult("success","");
else
    ConsoleLogger::instance().logResult("error","unable to load the file");

Si tu dois l'écrire de la sorte, tu en auras vite marre de logger tes différents événements

De plus, écrit de la sorte, il devient impossible de désactiver le logging, ce qui n'est pas forcément des plus opportuns, étant donné qu'il s'agit de logger... des informations de débuggage, et que cela ne devrait donc pas avoir lieu en "production"

Je te propose donc de passer par les macros préprocesseurs afin de gérer cela de manière plus facile.

Nous ferons en sorte que le logging ne soit activé que si le symbole DEBUG est défini ( sous gcc, cela donnerait une ligne de compilation proche de gcc monfichier.cpp -DDEBUG), et de simplifier un peu l'utilisation.

Nous allons donc créer un fichier d'en-tête séparé que nous veillerons simplement à inclure dans tout fichier dans lequel nous voulons logger des information.

Il prendrait la forme de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#ifndef DEBUG_MACRO_HPP // garde anti inclusion multiple
#define DEBUG_MACRO_HPP
#ifdef DEBUG // si le symbole DEBUG est defini
#include <consolelogger.hpp>
#include <cassert>
#define DEBUGACTION(x1,x2) \
ConsoleLogger::instance().logAction( x1 , x2 ,__FILE__,__LINE);
#define DEBUGEVENT(x1)\
ConsoleLogger::instance().logEvent( x1,__FILE__,__LINE);
#define DEBUGSUCCESS \
ConsoleLogger::instance().logResult("success","");
#define DEBUGWARNING(x1) \
ConsoleLogger::instance().logResult("warning", x1 );
#define DEBUGERROR( a, x1) \
ConsoleLogger::instance().logResult("error", x1 ); \
assert(a);
#else //si DEBUG n'est pas défini, on transforme tout en "no op"
#define DEBUGACTION(x1,x2) ;
#define DEBUGEVENT(x1) ;
#define DEBUGSUCCESS  ;
#define DEBUGWARNING(x1)  ;
#define DEBUGERROR(x1)  ;
#endif // symbole DEBUG
#endif //DEBUG_MACRO_HPP

Tu remarqueras que j'en ai profité pour lancer une assertion sur les erreurs... on pourrait faire pareil pour les avertissements, mais c'est à toi de juger

Le code prenant le logging en compte pourrait alors ressembler à

Code :

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

1
2
3
4
5
DEBUGACTION("lecture du fichier",thefile);
if(myressource.read(thefile))
    DEBUGSUCCESS
else
    DEBUGERROR(myressource.loaded(),"unable to load the file")

[Joel F]

Pourquoi tout le monde s'acharne a faire un singleton d'un logger ?
Ca me parait mieux niveau flexibiltié et moins casse geule d'avoir des logegr qui s'instancie et qui sont passés au éléments que l'on veut logger.

Ca permet aussi de pouvoir choisir qui logg comment ou vers quoi au niveau de l'instance et ca limite aussi les drames des singletons mal bouchonnés

[Astraya]

Pourquoi tout le monde s'acharne a faire un singleton d'un logger ?

je suis d'accord, un logger peut être aussi un RAII auquel on passe en paramètre le flux de sortie ostream.

[gl]

Pourquoi tout le monde s'acharne a faire un singleton d'un logger ?
Ca me parait mieux niveau flexibiltié et moins casse geule d'avoir des logegr qui s'instancie et qui sont passés au éléments que l'on veut logger.

Ca permet aussi de pouvoir choisir qui logg comment ou vers quoi au niveau de l'instance et ca limite aussi les drames des singletons mal bouchonnés

J'aurais plutôt tendance à dire "Pourquoi tout le monde s'acharne à développer son logger" alors qu'il en existe déjà, par exemple dans POCO. Il me semble aussi avoir vu un truc dans le sandbox boost.

Sinon +1 sur le reste. Je ne vois pas en quoi il est avantageux d'avoir un logger singleton.

[Goten]

Tout comme joel. Ou encore mieux comme gl .. Un logger c'est pas trivial autant évité le NIH.
Par contre c'est pas dans la sandbox boost.log a été officiellement accepté dans boost .

[gl]

Par contre c'est pas dans la sandbox boost.log a été officiellement accepté dans boost .

Il est déjà releasé ou il ne vient qu'avec la 1.45 ? Car je ne l'ai pas trouvé dans la 1.44.

[Joel F]

J'aurais plutôt tendance à dire "Pourquoi tout le monde s'acharne à développer son logger" alors qu'il en existe déjà, par exemple dans POCO. Il me semble aussi avoir vu un truc dans le sandbox boost.

Boost.Log ets dispo dans le trunk de mémoire. Mais oui, pourquoi rerererefaire un logger :E