Trop de log tue le log

Bonjour à tous o/

Je suis en train de développer un moteur de jeu et bien évidement, je me suis muni d'un log que je chéri beaucoup, voire trop !?
En effet, je signale toutes les actions que fait mon moteur ( changement de scène, instanciation d'objet, chargement de ressource ). C'est bien utile, surtout si j'ai un bug. J'ai également mis en place un système de niveau d'alerte pour plus ou moins détaillés les actions et ainsi ne pas être trop "floodé" dans le log de sortie. Je peux également choisir l'entrée standard ou d'écrire dans un fichier ( peut être plus rapide ? ).

Le faite est que dans le code, je me retrouve avec des;

Citation:

---

MonLog << "L’Objet truc est détruit !\n";

---

un peu partout.

Je me demande si cela n'est un coups en calcul supplémentaire et inutile, notamment pour une version Release.

Alors je me demande si je dois pas plutôt effectuer un test comme;

Citation:

---

#ifdef _DEBUG
MonLog << "L’Objet truc est détruit !\n";
#endif

---

Est-ce bonne méthode dans ce cas là ? Que feriez-vous ? Qu'en pensez vous ?

Tu peux définir plusieurs niveaux de LOG, plus ou moins bavards, en fonction d'un paramètre d'entrée.

En RELEASE à priori on n'a besoin que d'un LOG minimaliste, donc oui usage de _DEBUG là où le bavardage est intense.

Aussi, éviter les iostream et utiliser directement l'API système (windows ?). Les iostream sont réputés pour leurs médiocres perfomances...

Sous Windows, OutputDebugString() est sympa en conjonction avec dbgview.exe.

Citation:

---

Envoyé par camboui

Aussi, éviter les iostream et utiliser directement l'API système (windows ?). Les iostream sont réputés pour leurs médiocres perfomances...

Sous Windows, OutputDebugString() est sympa en conjonction avec dbgview.exe.

---

Oula j'ignorais cela, merci beaucoup :ccool:

a coup de macros

Code:

---

1 2 3 4

#define LOG(s)\ #ifdef _DEBUG MonLog(s) #endif

---

au lieu d'appeler MonLog, tu appeles LOG

edit:
oops

Citation:

---

The resulting completely macro-replaced preprocessing token sequence is not processed as a preprocessing directive even if it resembles one.

---

edit2:
la symmetrique est ok

Code:

---

1 2 3 4 5

#ifdef DEBUG #define LOG(s) MonLog(s) #else #define LOG(s) #endif

---

Citation:

---

Envoyé par galerien69

Code:

---

1 2 3 4 5

#ifdef DEBUG #define LOG(s) MonLog(s) #else #define LOG(s) #endif

---

---

Le problème de ce genre de macros est qu'il est difficile de les étendre correctement à plusieurs arguments.
Je préfère pour cette situation utiliser l'astuce suivante :

Code:

---

1 2 3

#define LOG(lvl) if(lvl>LOG_LEVEL) ; else MonLog   LOG(1) << "Ceci est un log" << endl;

---

Détail : Je préfère ne pas utiliser directement NDEBUG pour activer/désactiver les logs, on peut vouloir les logs en release dans certains cas.
Autre détail : Je préfère aussi avoir des logs activé sur un test dynamique, et non statique, et ne garder les logs activés statiquement que pour les cas où les performances sont réellement impactées. Ne pas avoir à recompiler pour modifier le niveau de log, voire même ne pas avoir à arrêter le logiciel, peut être précieux.

merci pour toutes ces précieuses astuces ;)

Citation:

---

Détail : Je préfère ne pas utiliser directement NDEBUG pour activer/désactiver les logs, on peut vouloir les logs en release dans certains cas.

---

Rien ne t'empeche de definir une macro pour logger en RELEASE et une pour logger en DEBUG.

Citation:

---

Autre détail : Je préfère aussi avoir des logs activé sur un test dynamique, et non statique, et ne garder les logs activés statiquement que pour les cas où les performances sont réellement impactées. Ne pas avoir à recompiler pour modifier le niveau de log, voire même ne pas avoir à arrêter le logiciel, peut être précieux.

---

oui ca peut se concevoir.

Citation:

---

Le problème de ce genre de macros est qu'il est difficile de les étendre correctement à plusieurs arguments.

---

ouais, enfin j'emets quelques reserves sur l'argument, car il ne prend valeur que si le nombre d'arguments est variant LOG()(12,a==NULL) ce qui est un peu limite pour un log.

Mais l'approche est interessante:)

edit:
comment modifierais-tu le niveau de log sans avoir a arreter le logiciel?

En passant une variable au macro et non une constante ? (et en abaissant la valeur de la variable en dessous de LOG_LEVEL lorsqu'on veut logger)

je présume que c'est log_level la variable. la question, c'est comment gérer la modification de cette variable de manière pas trop lourde et safe. Que se passe-t-il si subitement les logs affluent en trop grand nombre?

etc...
(j'ai pas de réponse, c'est par curiosité)

Tiens, à propos, il n'existe pas une petite bibliothèque de log ?
Il y a eu des discussions sur le sujet par le passé, sans rien de bien concret si j'ai bon souvenir.

Citation:

---

Envoyé par camboui

Tiens, à propos, il n'existe pas une petite bibliothèque de log ?
Il y a eu des discussions sur le sujet par le passé, sans rien de bien concret si j'ai bon souvenir.

---

tu peux essayer log4cpp

http://log4cpp.sourceforge.net/


ou celui developpé par g****e
http://code.google.com/p/google-glog/

ou ...

mais un logger simple avec des niveaux de trace n'est pas le truc le plus compliqué a faire.

Je suis en train d'utiliser Boost.Log, c'est top mais pour les inexperimentés mieu vaut attendre que ça soit mis dans une release officielle de boost.

Sinon conseils de log dans les jeux:

1. Les macros comme décris ici,
2. déléguer l'écriture du fichier de log à un logiciel externe: tu envoie les messages de log sur le réseau, ce qui fait que c'est plus ton appli qui perds du temps à gérer / trier les logs (evidement, dans le cas ou t'as besoin de perfs et de logs a la fois).
3. sort quelque chose de triable et fait en sorte qu'il ya ait moyen de filtrer à la lecture. Par exemple avec du xml ou du JSon tu peux faire une petite page web qui trie automatiquement tout ce que tu veux de manière interractive.

Enfin bref, les logs c'est tout un domaine, ondirait pas comme ça...

et bien voilà, j'ai mixé toutes vos meilleurs idées et effectivement, en mode "release", je gagne maintenant quelques FPS sur mon appli test.

Merci à tous :ccool:

(c'est toujours sympa de débattre et s'échanger des astuces, ça fait un peu comme un "Guru of the week" version developpez.net :) )