Discussion :

[franck_92]

bonjour

quelqu un connaitrait un script qui insere des logs automatiquents dans du code c++ existant ?

merci

[Alp]

Peux-tu détailler un peu plus ?
C'est surtout l'expression "insérer des logs dans du code C++" qui me chagrine.

Tu veux un objet dans ton code qui s'occupe de logger des informations dans un fichier ?

[franck_92]

injection du code du logger dans le corps de chaque methodes
ceci de maniere automatique dans du code existant C++

[Mat007]

Salut,

Tu es sûr que ce n'est pas plutôt d'une exécution pas à pas sous débogueur dont tu as besoin ?

Sinon, si vraiment je devenais un mordu des logs et que j'avais à faire ça, je me pencherais sur les 'aspects', cf. AspectC++.
Mais c'est peut-être un peu violent pour ce que tu as à l'esprit...

MAT.

[franck_92]

sur et certain , le debuggeur on l utilise quand on a localise le probleme.
les traces sont tres utiles pour des applications voluminueses en tailles (nb de lignes etc ... )

[koala01]

Salut,

Laurent Gomila présente la manière de mettre un logger dans le code, dans son tuto sur la conception d'un moteur 3D...

Cela se passe =>ICI<= (plus précisément dans la partie qui traite des outils )

[Mat007]

sur et certain , le debuggeur on l utilise quand on a localise le probleme.
les traces sont tres utiles pour des applications voluminueses en tailles (nb de lignes etc ... )

Les traces sont surtout utiles quand tout le reste a échoué.
En particulier lorsqu'on tente de maintenir une grosse application monolitique développée sans tests...

Mais oui, dans ce contexte-là je comprends tout à fait qu'on y ait recourt.
Et je compâtis même, j'y suis passé et je ferais tout pour ne pas y retourner...

MAT.

[Luc Hermitte]

Très bien les logs pour :
- suivre ce qui se passe dans une appli fortement multithréadée. Car là, les tests (unitaires) n'aident pas vraiment à voir toutes les situations
- l'historique de l'exécution chez le client quand il a constaté une anomalie

Débuggueur:
- Génial pour analyser des core,
- Utile pour observer des interblocages


Sinon, avec un bon et vrai éditeur, au hasard vim, tu parcours tous les tags de définition de fonction que ctags t'a extrait, tu te positionnes dans chacune de ces fonctions, et ajoute un

Code :

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

SCOPEDLOG("[Identifiant de fonction qui va bien]");

(La macro RAIIsante SCOPEDLOG étant à développer pour s'intégrer au système de logs utilisé dans ton appli.)
Cela doit certainement pouvoir se faire en perl ou ruby si tu préfères.


Mais bon, faire ça au dernier moment sans réfléchir ... attention à l'automatisation.

[Mat007]

Salut,

Très bien les logs pour :
- suivre ce qui se passe dans une appli fortement multithréadée. Car là, les tests (unitaires) n'aident pas vraiment à voir toutes les situations

Je ne vois pas bien le rapport...
Ou alors c'est que les threads ne sont pas assez sous contrôle. Il y a des 'patterns' pour ça, le plus simple étant la 'message box'.
Tester en lançant plusieurs threads en parallèle ne sert certes à rien, mais ce n'est de toute façon pas la bonne méthode. Si on sépare correctement on peut tester les morceaux séparément, et si le code qui gère les points de synchronisation entre threads est suffisament simple, il n'a pas besoin d'être testé.

Mais peut-être qu'il existe une catégorie d'application pour laquelle ce n'est pas applicable ?
Tu as un exemple de contexte dans lequel les threads sont tellement imbriqués qu'il est impossible de tester unitairement ?

- l'historique de l'exécution chez le client quand il a constaté une anomalie

Si c'est un livrable et que ça rassure le client, alors là oui pas de problème.
Je comprends la démarche, c'est juste que je ne trouve pas que le jeu en vaille la chandelle.
Pour moi les logs c'est vraiment le tout dernier filet pour attraper ce qui a échappé au reste, et c'est un filet avec des sacrément gros trous quand même.

MAT.