[C++] Visual Studio (2005) Preprocessor _DEBUG checks

[Rygir]

Ik gebruik doorheen mijn code vaak iets als

code:

std::cout<<variabele<<std::endl;

om snel debug waarden te zien.

Natuurlijk zou ik ook kunnen watchen enzo en prullen met break points, maar ik vind dit onder gewone omstandigheden praktischer.

Ik heb er echter 2 problemen mee :

1. Bij GUI applicaties, ga je dan messageboxen tonen gaan (niet met cout natuurlijk, ik bedoel, ga je dan ter plekke messageboxen createn en die te voorschijn toveren?) - dat lijkt me namelijk helemaal niet netjes, dan kan tijdens een algoritme wel honderden messageboxen te voorschijn floepen. Veel fijner als je dat in een soort van logvenster zou kunnen tonen, of eventueel een speciaal debug venster. Iemand daar ervaring mee om dat netjes op te zetten?
2. Je hebt meerdere klassen. Je wilt niet altijd alles debuggen, maar je wilt ook niet overal de debug statements beginnen uit slopen als je ze later opnieuw nodig hebt. Dus, ik zet er #ifdef statements rond zo dat ik 1 statement moet definen en dan zijn alle debug opdrachten in een stuk weer actief.
   Tot zover alles goed. Nu groepeer ik een overzicht van al mijn debug statements meestal in een lijstje, zodat ik vanuit die lijst alles met behulp van comments aan & uit kan zetten. En nu komt het probleem : Blijkbaar is er iets mis met mijn include volgorde waardoor ik niks kan definen in die lijst, die ifdef blokken blijven inactief...

Ik zal het proberen te illustreren aan de hand van voorbeeld code :

C++: a.cpp

#include "b.h"

#ifdef _DEBUG
 #define DEBUG_A
 #define DEBUG_B
 #define DEBUG_C
#endif

int main()
{
#ifdef DEBUG_A
    cout<<something;
#endif
}

Hier werkt alles nog prima, want de _DEBUG token wordt gemaakt door visual studio als hij in Debug profiel staat, zodra ik naar release switch is alle nutteloze uitvoer weg.

C++: b.cpp

void func()
{
#ifdef DEBUG_B
    cout<<something;
#endif
}

C++: b.h

void func();

Het is vrij logisch dat hier de preprocessor block bij b.cpp niet actief is. Dat is natuurlijk omdat die geinclude werd alvorens die tokens werden gedefinieerd.

Dus, dacht ik even slim te zijn en omdat alle includes op de eerste regels moeten staan (anders negeert hij ze straal, vind ik persoonlijk vrij flauw, in php kan je toch includen waar je wilt en interessante dingen mee maken) heb ik een aparte .h file gemaakt met alleen maar die ifdef _DEBUG blok in, dus alle debug switches.

Wel, dat werkt zolang je in de IDE bezig bent, dan markeert hij die blokken netjes als actief. Maar als ik compileer zegt hij njet, er komt geen debug uitvoer. Hij staat nog altijd in debug modus en alles... ik heb het nog nooit eerder als vandaag meegemaakt dat hij in de IDE het ene zegt (op gebied van preprocessor blokken) en na compilatie het andere waar blijkt te zijn.

Ik vind het vrij straf...Hoe kan ik nu op een goeie manier een overzicht aansturen van debug switches om blokken code doorheen de code uit te schakelen, zonder elke file apart te moeten af gaan en daar telkens de juiste define aan te zetten? Ik veronderstel dat ik het lijstje van visual studio met WIN32 en _DEBUG kan aanvullen, maar ik zou die instellingen liever met rust laten en gewoon in code files bezig blijven, dat is overzichtelijker.

Bijvraagje : Waarom indenteert hij trouwens al die preprocessor statements zo knal tegen de linkerkantlijn (niet dus)?

[H!GHGuY]

Ik dacht dat Visual Studio de output van je process toont in het Output window zelfs al is het een GUI applicatie.
Daarnaast, als je MFC gebruikt bestaan er dacht ik wel trace macro's/functies die je kan gebruiken om debug traces naar VS te zenden tijdens debuggen.

[farlane]

Je moet je blok waar je de logging defines maakt in een header plaatsen en die includen vanuit je sources waar je ze nodig hebt, of ze als compiler parameter meegeven op de commandline ( /D switch als ik het goed heb ).

De definities van je macro's dienen net als inline functies bekend te zijn bij elke unit die die macro's gebruikt.

[Rygir]

H!GHGuY schreef op zondag 16 augustus 2009 @ 08:13:
Ik dacht dat Visual Studio de output van je process toont in het Output window zelfs al is het een GUI applicatie.

Ja dat doet die, maar dan heb ik geen controle over de weergave en ben ik nog steeds beperkt tot ascii uitvoer. Laten we even stellen dat ik test geluidssamples en afbeeldingen en filmpjes heb die ik tussentijds wil tonen.
En zelfs al is het tekst, dan loont het nog steeds om die op een fatsoenlijke manier te formatteren voor de leesbaarheid, en in velden in te delen etc...

Daarnaast, als je MFC gebruikt bestaan er dacht ik wel trace macro's/functies die je kan gebruiken om debug traces naar VS te zenden tijdens debuggen.

Traces? Bedoel je stack traces? Dat is niet echt wat ik zoek, het gaat mij meer om een handvol tussenresultaten op zinnige wijze te kunnen weergeven.

[Rygir]

farlane schreef op zondag 16 augustus 2009 @ 09:19:
...en die includen vanuit je sources waar je ze nodig hebt, ...De definities van je macro's dienen net als inline functies bekend te zijn bij elke unit die die macro's gebruikt.

Als ik het goed begrijp moet ik die header file die ik had afgesplitst van mijn main daarboven met macro switches dus includen in (bijna) elke file? Ik veronderstel dat ik bij een .h en .cpp file weg kan komen met het alleen in de .h file te includen? Maar dan snap ik niet waarom het daar wel verder "cascade"-rt... ow wacht dan is die expliciet geinclude en weer geinclude, in plaats van "toevallig" er boven verschenen in de code volgorde... (de main file werd natuurlijk nergens geinclude, een .h file wel).

[Phyxion]

Rygir schreef op zondag 16 augustus 2009 @ 07:04:
*snip*

Met VS kan je eigen build targets aanmaken, als je zelf één maakt met wat je precies wil moet dat volgens mij geen probleem zijn.

[ Voor 87% gewijzigd door Phyxion op 16-08-2009 10:00 ]

[farlane]

Rygir schreef op zondag 16 augustus 2009 @ 10:00:
[...]

Als ik het goed begrijp moet ik die header file die ik had afgesplitst van mijn main daarboven met macro switches dus includen in (bijna) elke file? Ik veronderstel dat ik bij een .h en .cpp file weg kan komen met het alleen in de .h file te includen? Maar dan snap ik niet waarom het daar wel verder "cascade"-rt... ow wacht dan is die expliciet geinclude en weer geinclude, in plaats van "toevallig" er boven verschenen in de code volgorde... (de main file werd natuurlijk nergens geinclude, een .h file wel).

In je voorbeeld heeft alleen a.cpp de definitie van de macro's dus alleen in a.cpp of files die je include vanuit a.cpp na je ifdef blok zal het goed werken. Needless to say dat volgorde afhankelijkheden zoveel mogelijk vermeden moeten worden.

Rygir schreef op zondag 16 augustus 2009 @ 09:56:
Traces? Bedoel je stack traces? Dat is niet echt wat ik zoek, het gaat mij meer om een handvol tussenresultaten op zinnige wijze te kunnen weergeven.

Er is een TRACE(...) macro die printf achtige dingen doet naar het output window.

[ Voor 56% gewijzigd door farlane op 16-08-2009 10:07 ]

[Rygir]

farlane schreef op zondag 16 augustus 2009 @ 10:03:
[...]
In je voorbeeld heeft alleen a.cpp de definitie van de macro's dus alleen in a.cpp of files die je include vanuit a.cpp na je ifdef blok zal het goed werken. <...>

ja dat is dus wat ik ook dacht, maar de praktijk juist was dat visual studio terwijl ik de code bekeek inderdaad aangaf dat alles na m'n ifdef blok (dat geinclude was via header file, omdat je includes niet onder een ifdef blok kan zetten) werkte... maar eenmaal gecompileerd bleek het toch niet gebeurd te zijn.

[Rygir]

Phyxion schreef op zondag 16 augustus 2009 @ 10:00:
[...]

Met VS kan je eigen build targets aanmaken, als je zelf één maakt met wat je precies wil moet dat volgens mij geen probleem zijn.

Een build target... zoals debug en release? Dat is eigenlijk wel leuk, alleen moet ik er dan nogal veel aanmaken. Plus ik weet nog niet hoe dat moet .

[H!GHGuY]

Probeer eens iets als

C++:

// mydebug.h

#define MODULE_X 1
#define MODULE_Y 2
#define MODULE_Z 4

#define ENABLED_MODULES MODULE_X | MODULE_Z

inline void debugprintf(module, const char* format, ...)
{
  if (!(module & ENABLED_MODULES))
    return
  // vprintf hier
}

#define DEBUG(format, ...) debugprintf(THIS_MODULE, format, __VA_ARGS)

// code:
#include "mydebug.h"

#define THIS_MODULE MODULE_X

void function()
{
  DEBUG("blah %d", 3);
}

edit: aangepast aan opmerking MLM. Ik zat nog zo te denken dat het 1 2 4 moest zijn en dan typ ik alsnog 3...

[ Voor 10% gewijzigd door H!GHGuY op 16-08-2009 15:27 ]

[MLM]

met als sidenote dat je dan wel machten van 2 als module "nummers" gebruikt.
in het voorbeeld hierboven staat #define ENABLED_MODULES 1 | 3, wat gewoon 3 is daarnaast gaat een test op MODULE_Y (2) ook gewoon matchen met 3
als je perse opvolgende nummers wilt hebben, gebruik dan (1 << MODULE_NUMMER) oid in de preprocessor

[Phyxion]

Rygir schreef op zondag 16 augustus 2009 @ 10:20:
[...]

Een build target... zoals debug en release? Dat is eigenlijk wel leuk, alleen moet ik er dan nogal veel aanmaken. Plus ik weet nog niet hoe dat moet .

Ja, zoals debug en release. Je kan in VS zelf ook build targets aanmaken, deze kan je dan aanpassen zoals je zelf wilt.

[Rygir]

Phyxion schreef op zondag 16 augustus 2009 @ 13:09:
Ja, zoals debug en release. Je kan in VS zelf ook build targets aanmaken, deze kan je dan aanpassen zoals je zelf wilt.

Da's interessant, moet ik eens opzoeken. Maar voor het moment voldoet een header file met #define flags die geinclude wordt overal prima. Zou nog leuker zijn moest er een soort switch zijn dat een file automatisch overal geinclude is (voor de <new> standaard library is dat zo toch).

Dat van GUI's voorzien van een debug module zal ik zelf moeten maken door een debug GUI te bouwen en daar mijn messages naar verstuurd te krijgen... om de code beknopt te houden kan ik hem misschien als een singleton implementeren, kan ik er gelijk overal aan en er van maken wat ik wil.

Uit curiositeit, welke aanpak gebruiken anderen voor debug output in hun project te beheren?

[NC83]

H!GHGuY schreef op zondag 16 augustus 2009 @ 10:57:
snip...

Als je WIN32 draait gebruik je de functie debugOutput om naar het visual studio output venster te schrijven

C++:

#ifndef _DEBUG 
#define DL_TRACE(message, ...) 
#else 
#define DL_TRACE(message, ...) debugOutput(message, __VA_ARGS__);
#endif 

//!output a log message without a channel 
#ifndef _DEBUG 
#define DLTRACE(log, message, ...) DLTRACECHANNEL(log, 0, message, __VA_ARGS__)
#else
#define DLTRACE(log, message, ...) DLTRACECHANNEL(log, 0, message, __VA_ARGS__); debugOutput(message, __VA_ARGS__);
#endif 

Dit zijn een paar van mijn Trace defines die ik gebruik om text te kunnen outputen. De rest wordt gedaan door van een ILoggableObject te erfen dat trace prefixes en de echte logs bij houdt. Zie hier. Ik output in debug naar zowel het outout window in VS als een file in release wordt er enkel naar een file geschreven en naar standard output.

[ Voor 81% gewijzigd door NC83 op 19-08-2009 11:53 ]

[.oisyn]

NC83 schreef op woensdag 19 augustus 2009 @ 11:37:
[...]

Als je WIN32 draait gebruik je de functie debugOutput om naar het visual studio output venster te schrijven

Waar komt die functie vandaan? Ik kan 'm niet vinden in de docs (en ik had er ook nog nooit van gehoord). Ben je niet in de war met OutputDebugString(), die je een string mee moet geven zodat je dus geen printf-style varargs kunt gebruiken (oftewel, eerst sprintf'en)?

[NC83]

.oisyn schreef op woensdag 19 augustus 2009 @ 11:49:
[...]

Waar komt die functie vandaan? Ik kan 'm niet vinden in de docs (en ik had er ook nog nooit van gehoord). Ben je niet in de war met OutputDebugString(), die je een string mee moet geven zodat je dus geen printf-style varargs kunt gebruiken (oftewel, eerst sprintf'en)?

Ja geloof het wel heb die code al een heele tijd terug zelf in een functie geplaatst die ik idd debugOutput heb genoemd. Oeps , misschien is werken na het halen van een release date niet zon goed idee.

C++:

inline void debugOutput( const char * format, ...) 
{
     static char buf[4096];
     va_list args;
     va_start( args, format );
     vsprintf_s( buf, format, args );
     va_end( args );
     sprintf_s(buf, 4096, "%s\n", buf);
     OutputDebugStringA( buf ); 
} 

[ Voor 20% gewijzigd door NC83 op 19-08-2009 12:00 ]

[Rygir]

Met wat hier gezegd is in het achterhoofd heb ik nu nog wat verfijningen aan mijn aanpak aangebracht in de tussentijd.
Wat ik heb geconcludeerd uit de antwoorden :
- Het gebruik van #define en #ifdef en vergelijkbaar is kennelijk toch niet "schandelijk"
- Er zijn zelfs andere mensen die preprocessor statements gebruiken voor debug output te scheiden (ik vraag me af als ik nu weer eens met java aan de slag moet hoe dat dan daar moet)
- De debug file moet overal geinclude worden.
- Debug en release kunnen aangevuld worden met andere build targets en dat zou kunnen helpen
- Traces zijn andere namen voor debug statements?

dus in mijn meest recente project ziet het er nu ongeveer als volgt uit :

code:

#ifdef _DEBUG //deze is standaard gedefinieerd als debug build target actief is, bij release dus niet.
    #define DEBUG_MODULE1
    #define DEBUG_MODULE2
    #define DEBUG_MODULE3
#endif

#ifdef DEBUG_MODULE1
    #define DEBUG_MODULE1_FUNCTIONALITEIT1
//  enz...
#endif

//enz voor elke module (een klasse, of een groep van klassen die sterk gekoppeld zijn) waar ik het nuttige acht

code:

#include "DEBUG_FLAGS.h"
#include <iostream>//etc

class A {
     A(){
        int a = x;//onzincode
        #ifdef DEBUG_MODULE1_FUNCTIONALITEIT1
               std::cout<<"constructor A"<<std::endl;
        #endif

        x.feedMe();//onzincode
      }
}

Analoog voor een klasse B enz, waarbij dan een andere modulenaam gebruikt wordt. Doorgaans zou ik ze dan ook DEBUG_A_CONSTRUCTOR of iets dergelijks genoemd hebben natuurlijk.

Goed; de voordelen die ik hiermee bereik :
- In release mode is er geen nutteloze code zelfs maar gecompileerd of terug te vinden in de executable. Dat wil zeggen, ik moet geen code aanpassingen doen om debug info er uit te strippen voor een release build of zo. Als iemand me kan zeggen hoe je dit in java bereiken kan dan zou ik dat zeer appreciëren!
- Er is een overzichtelijk centraal punten vanwaaruit je met verschillende niveaus van granulariteit kan aanpassen welke informatie wordt uitgeschreven
- Ik kan ipv cout statements natuurlijk ook cerr enzo gebruiken, maar ik kan ook, wat ik voor beknoptheid achterwege heb gelaten, een functie aanroepen die elders is gedefinieerd tussen #ifdef _DEBUG flags zodat die enkel bestaat in debug mode. Deze kan dan geavanceerdere trukjes uithalen, zoals opmaak of het zowel naar file als naar console uitschrijven of, zoals ik bij de nadelen beschrijf, het op een threadsafe stack pushen.

Nadelen :
- Include van file zorgt voor dependency van het hele project op 1 file, dat lijkt me niet de bedoeling, niet erg OO? High coupling, maar wel eenvoudig op te lossen natuurlijk.
- Uiteraard geen runtime controle over de "verbosity" van de applicatie. Dat vind ik niet noodzakelijk een probleem.
- Console output is TRAAG. Ik had namelijk voor dat mijn statements voor het verzenden van berichten over het netwerk kort waren, maar bij ontvangst door alles uit te schrijven er wel dubbel zoveel tekst was. Gevolg : Mijn queue liep vol zodat zelfs tot 5 seconden nadat ik was gestopt met zenden hij nog steeds berichten van zijn threadsafe queu aan het poppen was. In release mode was dit geen probleem en lag de framerate gelijk een pak hoger (er waren haperingen bij het outputten van bepaalde ruwe bytes naar console). Om die reden wil ik dus ook dat de debug output aan "maximale framerate" van de weergave draait en niet forceert dat de framerate zo traag is dat elk frame alle debug statements kunnen uitgeschreven worden. Daarvoor moet ik in kritieke secties kunnen piepen telkens ik een frame render of iets dergelijks, en in tussentijd kan de andere thread al tientallen stappen hebben opgelost voor hij weer eens komt kijken naar tussenresultaten.

Voor pakweg een teller die bijhoudt hoeveel frames er gemaakt zijn, hoeveel pakket zijn binnengekomen is dat perfect. Voor iets waarvan je de exact uitvoer stappen wilt analyseren heb ik nu een probleem, ik moet een custom "console" maken binnen een graphics engine, zodat ik daar tekst statements op kan pushen...en dan daarvoor dus een queue waarop ik telkens berichten enqueue en die dan asap op de console getoond worden vanuit een aparte gui thread.

Dit zou de huidige situatie moeten illustreren, volgende bericht leg ik uit wat ik nu graag anders zou zien.

[Rygir]

Dus de huidige situatie in 3 stappen:
> Ik heb een project
> Ik heb daarin een user interface, laat ons zeggen, een window, of de tekstballonetjes van Windows die overal bijkomen of zo.
> Ik heb nu her en der verspreid door mijn code toegang nodig tot die UI klassen, om daar "notifications" aan te kunnen sturen. Tot op het punt waarop ik bijna wil zeggen van, pech, nu maak ik het global static public totdat ik er vanuit eenderwelke code rechtstreeks een handle naar heb.

Dat laatste is dus mijn probleem; Volgens mij is dat niet de bedoeling?

---

Een voorbeeldje is "er is een netwerkpacket aangekomen", dat zou een event moeten genereren waarop de UI al dan niet naar keuze kan reageren door daarvoor een bericht weer te geven, dus ik zou een soort van globale berichtenstack kunnen maken of zo waar ik die allemaal op tast, maar dat zijn details. het probleem is dat ik me afvraag of het wel verantwoord is om de hele user interface vanuit elke klasse in het hele project , al dan niet via singleton pattern, beschikbaar te maken....

Zo wil ik ook bijvoorbeeld periodiek de lengte van stacks en queues tussen threads in in de gaten houden, om zeker te zijn dat die niet aan het opstapelen zijn per ongeluk. Dus dan moet eigenlijk net het omgekeerde, de UI moet dan aan eenderwelk object kunnen...

Ik bedoel, het is vrij simpel om te zeggen hier, monitor dit object, maar dan bind ik die twee klassen aan elkaar en ik zou een generieke oplossing willen verzinnen maar daar kom ik dus niet echt uit, ik moet altijd één of andere klasse beschikbaar maken in elke klasse in heel mijn project om de uitvoer te krijgen waar ik hem wil en dat kan onmogelijk de bedoeling zijn.

---

Heeft er iemand een tip voor een pattern of constructie van een UI element dat je in eenderwelke code kan herbruiken en bvb kan dienen om events uit andere klassen te tonen, zonder aanpassingen aan de code van het te debuggen project en liefst zonder dat (in de notify-ende klassen) daarvoor extra bindingen met UI klassen komen?

[Rygir]

Ow en ik heb ook niet echt veel nuttigs gevonden in build targets (naast het genoemde voordeel tussen debug en release van die _DEBUG en het koppelen met andere dll versies e.d.) om te helpen bij het debuggen van bepaalde gegevens? Waarom zouden extra build targets mij kunnen helpen?

[RobIII]

Rygir; ik zie je in minder dan 10 minuten het topic 3 keer schoppen; gebruik de edit knop ( ) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig.

[Rygir]

RobIII schreef op vrijdag 30 april 2010 @ 02:15:
Rygir; ik zie je in minder dan 10 minuten het topic 3 keer schoppen; gebruik de edit knop ( [afbeelding] ) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig.

Euh, dat was gewoon omdat het van die lappen tekst waren, dat ik ze liever per onderwerp sorteerde. Dat maakt makkelijker voor scannend lezen . Sowieso, op 10 minuten tijd gaat dat niet veel effect hebben he ?

Spijtig genoeg heb ik het kennelijk nog te lang gemaakt en mensen de interesse om te lezen ontnomen... Misschien is het geen vraag die iedereen zich stelt ?