Le logger en c++

[edit]: ceci est un fork d'une autre discussion.
r0d.


Pour un logger je serais tenter de dire Variable globale (comme std::cout).

Citation:

---

Envoy� par r0d

Bonjour � tous,

Ce que j'appelle un "objet omnipr�sent" c'est une instance d'une classe dont on va avoir besoin quasiment partout dans le programme. Cela arrive assez fr�quemment. Par exemple un logger, ou une classe de gestion de session sur les applis de type serveur, etc.

Pour g�rer cela, je vois deux solutions:
1. Le singleton, b�te et bourrin
2. Le pointeur que l'on va se trimbaler partout

Ca doit se sentir dans la forme de ma prose: aucune de ces 2 solutions ne me pla�t. Mais je n'en vois pas d'autre. Auriez-vous d'autres id�es � proposer?

---

Pour une classe loggueur, le singleton me semble quand m�me la meilleure approche. (pourtant je suis pas un grand fan du singleton).
Attention quand m�me au niveau de l'ordre de destruction du singleton, il en faut un plut�t bien pens� offrant plusieurs choix de gestion de dur�e de vie. (et l� je dis, loki ftw).

Salut,

Pour des fonctions de log par exemple, le singleton peut �tre masqu� par des fonctions libres plus simples : trace_message, trace_erreur, trace_debug... qui ont l'avantage de pouvoir �tre d�sactiv�e en release.

c'est forcer de l'objet la ou il y en a pas non ?
si tu n'as qu'une instance et que tout le monde y a acces je pense que ca releve plus de la programmation sequentielle que de la programmation objet.

un logger, c'est jamais qu'un printf en gros. au lieu de te trimballer un singleton ou une instance, peut etre devrais tu publier des methodes statiques et qu'une classe (singleton) soit utilis�e dans l'impl�mentation sans que ca se voie pour l'appelant

je veux dire, si tout le monde fait

Code:

---

Logger::instance()->log("blabla");

---

je ne vois pas pourquoi ca serait plus moche de faire

Code:

---

Logger::log("blabla");

---

quitte a avoir un objet logger quelque part.

[edit]comme 3Darchi. J'arrive souvent apres la bataille ces derniers temps...

[HS]
Pour le logger, j'aime bien ajouter quelques macros, afin de pourvoir faire �a:

Code:

---

1 2	LOG_WARNING << "warning message" << param; LOG_ERROR << "warning message" << param;

---

[/HS]

Code:

---

log("warning message" << param);

---

avec log une macro :

Code:

---

1 2	#define log(msg) Logger()<< msg;

---

cr�e un logger temporaire, colle des trucs dedans. Libre au logger temporaire de faire ce qu'il lui chante . l'avantage c'est que tu peux compl�tement retirer le code en config optim.

Sauf qu'une telle macro n'est pas tr�s "safe" (essaye de mettre une ',' dedans par exemple). La mani�re classique d'�crire une macro de log serait plut�t :

Code:

---

1 2	#define LOG if(logDisabled) ; else log LOG << "Test";

---

Avec logDisabled une constante connue � la compilation, le code g�n�r� devrait �tre identique � rien du tout dans le cas o� le log est inactif.

je ne vois pas pourquoi c'est pas safe, qu'est ce qui se passe avec une virgule ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#define TOTO(x) cout << x; template<class A, class B> int f(A a, B b) { return a*b; }   int main() { TOTO(f<int, int>(3,4) << endl); }

---

Code:

---

1 2	1>main.cpp(26): warning C4002: too many actual parameters for macro 'TOTO' 1>main.cpp(26): error C2143: syntax error : missing ',' before ';'

---

ce sujet semble int�resser. Alors pour �viter un overflow, j'ai fais un fork de la discussion d'� c�t� ici.

A noter que loglite (qui me semble plut�t pas mal � permi�re vue) est actuellement candidate pour �tre int�gr�e � boost.

Je pense qu'il y a deux types de logs. Le log de debug que tu veux d�sactiver en production et le log en production dont tu as besoin parce qu'il y aura toujours un probl�me quelque part.

Enfin personnellement, et m�me si en milieu industriel on ne peut pas se permettre de mettre un programme bugg� en prod, il y a toujours quelque chose qui fait que l'on a besoin de logs.

J'ai des projets o� j'ai plusieurs fa�ons de logger:

- Des logs directement dans le buffer du kernel pour des machines embarqu� sous linux
- Des logs fichiers journaliers
- Des logs envoy�s � un serveur distant pour �tre mis en base de donn�e et accessible sur les outils de monitoring globaux, avec traduction etc..

Sinon pour en revenir au sujet j'ai pas mal utilis� log4cpp en singleton, avec extensions des classes existantes