bonjour
quelqu un connaitrait un script qui insere des logs automatiquents dans du code c++ existant ?
merci
Version imprimable
bonjour
quelqu un connaitrait un script qui insere des logs automatiquents dans du code c++ existant ?
merci
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 ?
injection du code du logger dans le corps de chaque methodes
ceci de maniere automatique dans du code existant C++
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.
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 ... )
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 ;))
Les traces sont surtout utiles quand tout le reste a échoué.Citation:
Envoyé par franck_92
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.
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
(La macro RAIIsante SCOPEDLOG étant à développer pour s'intégrer au système de logs utilisé dans ton appli.)Code:SCOPEDLOG("[Identifiant de fonction qui va bien]");
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.
Salut,
Je ne vois pas bien le rapport...Citation:
Envoyé par Luc Hermitte
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 ?
Si c'est un livrable et que ça rassure le client, alors là oui pas de problème.Citation:
Envoyé par Luc Hermitte
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.