Discussion :

[Scheb]

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;

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;

#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 ?

[camboui]

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.

[Scheb]

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

[Invité]

a coup de macros

Code :

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

1
2
3
4
#define LOG(s)\
#ifdef _DEBUG
 MonLog(s)
#endif

au lieu d'appeler MonLog, tu appeles LOG

edit:
oops

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 :

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

1
2
3
4
5
#ifdef DEBUG
#define LOG(s) MonLog(s)
#else
#define LOG(s)
#endif

[JolyLoic]

Code :

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

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 :

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

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.

[Scheb]

merci pour toutes ces précieuses astuces

[Invité]

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.

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.

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?

[Invité]

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)

[Invité]

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é)

[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.

[jabbounet]

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.

[Klaim]

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...

[Scheb]

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

(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 )