[Alg/C++] Debug print info stroom beheren

[12_0_13]

Hallo,

ik heb een beetje een ontwerp probleem, het gaat over debug informatie. Ik heb nl. een multihtreaded programma, en ik schrijf nu alle debug print informatie naar de cout. Dit komt nu allemaal door elkaar te staan en wat ik eigenlijk wil is een mooi mechanisme om dit op te lossen, het liefst zonder (al te veel) performance verlies.

Nou weet ik dat het kan met bijv #ifdef DEBUG etc, maar dit maakt het niet leesbaarder en het blijft lastig de verschillende informatie-bronnen te scheiden. Het zou kunnen met een functie call en een argument dat aangeeft waar het vandaan komt, maar dat is waarschijnlijk wat trager.

Ik weet dat het met Aspect Oriented programmeren de mooise oplossing zou geven, maar ik weet niet hoeveel tijd het kost om dat weer in te voeren in mijn project.

Is hiervoor een standaardoplossing? Hebben jullie al eens zoiets gemaakt of gedaan? Wat is hiervoor een goeie aanpak? Waar hebben jullie goeie (of slechte) ervaringen mee?

Alvast bedankt!

[LazySod]

In mijn ervaring is het probleem niet zozeer de leesbaarheid van de logging, maar de (te) grote hoeveelheid ervan.

Zelf gebruik ik hier (werk) een eenvoudige methode waar iedere logmelding geprefixed wordt door de identificatie van de thread waar de melding vandaan komt en dat is goed leesbaar. Een extra parameter meegeven aan de logmelding-functie danwel het logmechanisme zelf leren uit te zoeken waar iets vandaan komt zal de performance echt niet storen, behalve als je veel en veel te veel informatie gaat loggen.

[12_0_13]

Tja.. ik heb nu het probleem dat het programma na een uur of langer "hangt" dwz, een of andere thread komt in een deadlock. Ik kan dat niet achterhalen uit de code, dus is zou graag bijhounden wat er allemaal gebeurd voordat het mis gaat. Daarvoor moet echter wel het e.e.a. gelogd worden, en dus is de hoeveelheid erg groot (helaasch)

[LazySod]

Kun je dit probleem niet makkelijk traceren door iedere thread op een geregeld tijdstip (zeg 1 keer per minuut) een melding te laten genereren? Dan weet je in ieder geval welke thread nog wat aan het doen is, en als je daarbij kan aangeven waarop de thread aan het wachten is, dan weet je vaak genoeg.

[Macros]

Je kan elke Thread met een timestamp naar zijn eigen logfile laten printen.

[MSalters]

In C++ kun je een macro conditioneel definieren. Je houdt dan de #ifdef NDEBUG op een plek. In het geval van een debug versie definieer je een LOG macro die keurig de logging doet. In het geval van een release build wordt het een nullstream object, met allemaal ge-inline'de no-op operator<<'s. De optimizer veegt dan veel tot alles onder het tapijt.

[bramseltje]

is het niet mogelijk om elke thread een simpele file te laten schrijven? Je maakt in het begin een file objectje aan (fstream denk ik zo) en dan gebruik je die in plaats van je stdout (cout) om naar toe te schrijven?

kan heel simpel, want je hebt elke thread apart in een file (ik neem aan dat ze iets van een id hebben ofzo, dan kun je daar de filenaam mee maken).

En volgens mij is het schrijven met cout al zo traag dat je het verschil met naar een file schrijven niet echt zult merken...

Of raaskal ik nu heel hard?

[Bobco]

Zelf doe ik helemaal niets met C++ maar met Java. Daar is Log4J een bijzonder populaire logging toolkit die ook geport is naar C++. De status van de port is mij een beetje onduidelijk als ik deze link volg, maar dat moet je zelf maar even bekijken.

Log4J is in ieder geval prima in staat om vanuit een aantal threads te loggen naar een centrale locatie en daarbij ook informatie te geven over welke thread precies wat logt.

[12_0_13]

Ah.. dat ziet er wel uit als een bruikbare toolkit! Ik zal er eens mee experimenteren.

In tussen had ik zelf al een socket based multiple file logger geschreven, maar deze ziet er iets uitgebreider ene beter uit