[c++] compilen, debuggen, etc.

[Memorice]

Er zijn vele tutorials en boeken geschreven over de taal c++, waarmee je de taal prima kunt leren. Echter heb ik tot op heden nog geen goede tutorial/boek gevonden waarin het compilen, linken, debuggen, etc. van c++ goed behandeld wordt. Ik ben niet zozeer op zoek naar hoe je moet debuggen in het algemeen (breakpoints, waardes naar de output, etc.) en ook niet het debuggen met behulp van een IDE als Visual Studio.

Ik ben vooral geinteresseert in hoe je via de commandline (zo basic mogelijk dus) het beste c++ kunt compilen en debuggen (en dus niet alleen het intypen van commando's, maar ook daadwerkelijk begrijp wat ik aan het doen ben). Bijv. met behulp van g++, etc.

Mijn doel is vooral om de taal c++ beter te beheersen, want ik kan wel redelijk met c++ overweg, maar ik beheers het niet zo goed als de talen java en C#. Voor mijn gevoel komt dit omdat ik de taal java geleerd heb met een simpele editor en vervolgens compilen via de commandline, terwijl ik met c++ vooral ervaring heb in Visual Studio.

[H!GHGuY]

De tools die je zoekt zijn waarschijnlijk:
gcc, make, gdb

Binnen gcc kun je dan met de command-line opties spelen zoals -c (compile only), -S, -E (pre-process only).
Je kan ook even met objdump, nm en andere tools de binaries terug ontleden. Verder kun je je nog wat inlezen over ld (dynamic linker) en het laden van dynamische libraries. ar (archiver), libtool, e.a.

[Verwijderd]

Memorice: Jij weet wat je wilt!

Maar wat wil je van ons?

[ Voor 8% gewijzigd door Verwijderd op 24-10-2009 10:29 ]

[Comp_Lex]

Je kunt ook wel eens even kijken naar GNU Autotools.

[Laurens-R]

Wat voor mij heeft geholpen: verdiep je in het onderliggende platform. Zo ben ik me ook laatst gaan verdiepen in x64 assembly en de intel manuals omdat ik in de bovenliggende taal (C++) nog niet helemaal door had waar nou precies de nuances lagen tussen x86 en x64 (los van het feit dat bepaalde type variabelen groter zijn geworden). En deze nuances kunnen behoorlijk interresant zijn bij het compilen, linken en optimizen.

Wellicht ook een idee (gezien je focus op het compilen-linken deel) om je te verdiepen in de werking van compilers. Niet zozeer om een compiler te maken, maar om meer inzicht te krijgen in wat bepaalde parameters/instructies voor invloed hebben op het eindresultaat.

Het zijn wellicht wat die-hard skills die je zeer sporadisch zal gebruiken (of helemaal niet), maar het geeft wel inzicht op wat een highlevel beslissing in C++, Java of C# op een lowlevel kan betekenen (al dan niet in een onderliggende VM).

[ Voor 23% gewijzigd door Laurens-R op 24-10-2009 14:37 ]

[Memorice]

H!GHGuY schreef op zaterdag 24 oktober 2009 @ 10:26:
De tools die je zoekt zijn waarschijnlijk:
gcc, make, gdb

Inderdaad, al was ik vooral op zoek naar gdb :-)

Verwijderd schreef op zaterdag 24 oktober 2009 @ 10:28:
Memorice: Jij weet wat je wilt!

Maar wat wil je van ons?

Weten hoe jullie geleerd hebben om gcc, gdb, etc. te gebruiken. Wellicht dat er goede beknopte tutorials zijn.

Comp_Lex schreef op zaterdag 24 oktober 2009 @ 11:12:
Je kunt ook wel eens even kijken naar GNU Autotools.

Thx voor de tip.

EvilB2k schreef op zaterdag 24 oktober 2009 @ 14:34:
Wat voor mij heeft geholpen: verdiep je in het onderliggende platform. Zo ben ik me ook laatst gaan verdiepen in x64 assembly en de intel manuals omdat ik in de bovenliggende taal (C++) nog niet helemaal door had waar nou precies de nuances lagen tussen x86 en x64 (los van het feit dat bepaalde type variabelen groter zijn geworden). En deze nuances kunnen behoorlijk interresant zijn bij het compilen, linken en optimizen.

Wellicht ook een idee (gezien je focus op het compilen-linken deel) om je te verdiepen in de werking van compilers. Niet zozeer om een compiler te maken, maar om meer inzicht te krijgen in wat bepaalde parameters/instructies voor invloed hebben op het eindresultaat.

Het zijn wellicht wat die-hard skills die je zeer sporadisch zal gebruiken (of helemaal niet), maar het geeft wel inzicht op wat een highlevel beslissing in C++, Java of C# op een lowlevel kan betekenen (al dan niet in een onderliggende VM).

Ik heb wel een redelijk idee hoe compilers en verschillende architecturen werken (in het verleden zelf een compiler geschreven). In principe is mijn probleem vooral dat ik gewend ben aan andere talen, waaronder java en C#. Wanneer ik daar een error krijg is dat vaak in no-time gefixed, doordat ik precies weet waar ik moet zoeken. In c++ echter, wanneer ik daar een error krijg heb ik vaak geen idee wat dit precies veroorzaakt, doordat ik niet precies weet wat er achter de schermen gebeurd (een IDE als Visual Studio neemt teveel werk uit handen).

[Verwijderd]

MEMORICE schreef op zaterdag 24 oktober 2009 @ 16:56:


Weten hoe jullie geleerd hebben om gcc, gdb, etc. te gebruiken. Wellicht dat er goede beknopte tutorials zijn.

Kijk maar eens op Google. Ik kreeg meer dan 10 000 hits voor "gdb tutorial".

[durian]

[b][message=32795293,noline]
Ik ben vooral geinteresseert in hoe je via de commandline (zo basic mogelijk dus) ...

Dat vind ik een groot misverstand. De command line is juist veel krachtiger dan wat de fabrikant eventueel in een GUI stopt. Het is als een taal, je krijgt allemaal tooltjes die je zelf op krachtige manieren kunt combineren. Een GUI is als voorgedrukte kaartjes die je kan laten zien. Veel meer basic dan de command line.

Dat gezegd hebbend, als je Linux draait krijg je alles wat je nodig hebt, gcc, de automake tools, gdb, editors en alle command line tools die je kan verzinnen.

[NC83]

In VS kun je zelf de command line opties aan passen in de GUI door naar de command line opties te gaan in de "C++" en "Link/Librarian" secties.

C++ compile en link errors zijn erg makkelijk na te lezen op internet wat ze beteken door in google te zoeken op "Cxxxx" of "LNKxxxx".

En voor debuggen kun je gewoon een crash dump openen in VS en dan VS vertellen waar de source files zijn voor de applicatie. Je krijgt dan een call stack te zien en vandaar is het debug werk meestal hetzelfde als een crash als je vanuit VS runt.

[ Voor 30% gewijzigd door NC83 op 24-10-2009 20:01 ]

[Memorice]

Verwijderd schreef op zaterdag 24 oktober 2009 @ 17:22:
[...]

Kijk maar eens op Google. Ik kreeg meer dan 10 000 hits voor "gdb tutorial".

Dit is mijn probleem ook, een overvloed aan informatie. Net zoals sommige boeken/tutorials beter zijn als je een taal wilt leren, zullen er ook betere tutorials zijn mbt tooltjes als gdb. Mijn vraag is dus wat jullie ervaring hiermee is, welke tutorials jullie kunnen aanraden, zodat ik ze niet alle 10 000 zelf hoef te bekijken Immers worden hier ook boeken/tutorials voor het leren van een taal aangeraden, maar kon ik geen topic vinden waarin tutorials aangeraden worden voor het leren omgaan met tools als gdb.

durian schreef op zaterdag 24 oktober 2009 @ 17:29:
[...]

Dat vind ik een groot misverstand. De command line is juist veel krachtiger dan wat de fabrikant eventueel in een GUI stopt. Het is als een taal, je krijgt allemaal tooltjes die je zelf op krachtige manieren kunt combineren. Een GUI is als voorgedrukte kaartjes die je kan laten zien. Veel meer basic dan de command line.

Dat gezegd hebbend, als je Linux draait krijg je alles wat je nodig hebt, gcc, de automake tools, gdb, editors en alle command line tools die je kan verzinnen.

Met het woord basic bedoelde ik eigenlijk niet dat het minder krachtig is, maar dat je er zelf meer besef van hebt wat je doet (doordat er geen fancy grafische laag tussen zit). Ik heb idd in linux alles wat ik nodig heb, alleen moet je wel weten wat je hebt en hoe je het moet gebruiken.

NC83 schreef op zaterdag 24 oktober 2009 @ 20:00:
In VS kun je zelf de command line opties aan passen in de GUI door naar de command line opties te gaan in de "C++" en "Link/Librarian" secties.

C++ compile en link errors zijn erg makkelijk na te lezen op internet wat ze beteken door in google te zoeken op "Cxxxx" of "LNKxxxx".

En voor debuggen kun je gewoon een crash dump openen in VS en dan VS vertellen waar de source files zijn voor de applicatie. Je krijgt dan een call stack te zien en vandaar is het debug werk meestal hetzelfde als een crash als je vanuit VS runt.

Ik weet dat je met VS ook alles kunt, alleen wil ik het graag via een commandline (liefst remote via ssh), omdat mijn code draait op een zware server (met grote hoeveelheden data).

[Olaf van der Spek]

Wat is het voordeel van gdb boven VS als beide bruikbaar zijn op je platform? Onder Linux gebruik ik cname om te builden, maar van gdb heb ik echt geen kaas gegeten.

[Memorice]

Olaf van der Spek schreef op zaterdag 24 oktober 2009 @ 21:57:
Wat is het voordeel van gdb boven VS als beide bruikbaar zijn op je platform? Onder Linux gebruik ik cname om te builden, maar van gdb heb ik echt geen kaas gegeten.

Beiden zijn niet bruikbaar op mijn platform, dus dan geniet gdb wel de voorkeur ;-) Voor de rest is het net waar je jezelf het meest comfortabel mee voelt.

[Olaf van der Spek]

Over welk platform gaat het dan?

[durian]

[b][message=32797963,noline]
Met het woord basic bedoelde ik eigenlijk niet dat het minder krachtig is, maar dat je er zelf meer besef van hebt wat je doet (doordat er geen fancy grafische laag tussen zit). Ik heb idd in linux alles wat ik nodig heb, alleen moet je wel weten wat je hebt en hoe je het moet gebruiken.

Ah, okay!

Ja, de learning curve met een command line is wat steiler omdat je niet meteen kan zien wat je allemaal kan doen.

[Reptile209]

durian schreef op zaterdag 24 oktober 2009 @ 23:09:
[...]

offtopic:
Durian (bij gebrek aan andere contact-opties): let bij het knippen in een quote even op wat je weghaalt, nu staan er steeds halve titel-tags in je quotes die het alleen maar rommelig maken...

[kluyze]

Heb je het nu eigenlijk over debuggen tijdens het compilen? Als er dus compiler fouten naar boven komen? Of debuggen van een applicatie die juist gecrached is?

Bij debuggen tijdens compiling is het handig om een app of schil te hebben die eigenlijk de output van g++ in kleur zet, 'colorgcc' is een perl script. Hoe het juist werkt ed. kan je zelf even opzoeken, ik heb het nooit echt gebruikt.

Voor debugging van de app zelf heb ik wel al eens gespeeld met valgrind. Daarmee kan je zoeken of er memory leeks in je software zitten. Handig indien je een daemon of iets dergelijks aan het maken bent. (Buiten tools zoals gdb natuurlijk)

Verder lijkt het me gewoon handig dat je ergens iets doet met logging. Als ik iets wil debuggen in eender welke taal gooi ik er standaard een hoop printf's/echo's/System.out.println's/... tegen aan. Met eventueel een code in (bv 'DEBUG' + het lijnnummer, in c++ als ik me niet vergis met de macro '__LINE__). Eigenlijk vind ik dat zelf nog steeds de meeste snelle en simpele manier van debuggen.

[Olaf van der Spek]

kluyze schreef op zaterdag 24 oktober 2009 @ 23:21:
Eigenlijk vind ik dat zelf nog steeds de meeste snelle en simpele manier van debuggen.

Ik zie dat als teken dat je niet weet hoe een echte debugger werkt.

[ Voor 3% gewijzigd door Olaf van der Spek op 24-10-2009 23:42 ]

[Memorice]

Olaf van der Spek schreef op zaterdag 24 oktober 2009 @ 22:37:
Over welk platform gaat het dan?

Een cluster met 50 servers, 8 cores en 8 GB RAM per server en het OS is Ubuntu.

kluyze schreef op zaterdag 24 oktober 2009 @ 23:21:
Heb je het nu eigenlijk over debuggen tijdens het compilen? Als er dus compiler fouten naar boven komen? Of debuggen van een applicatie die juist gecrached is?

Vooral compile errors, maar ook bijv. simpele runtime errors. Bij simpele runtime errors kun je denken aan index out of bounds, null pointer, etc. Misschien zijn deze errors niet altijd even simpel, maar in vele gevallen hebben ze een duidelijke oorzaak die eenvoudig te traceren is.

kluyze schreef op zaterdag 24 oktober 2009 @ 23:21:
Bij debuggen tijdens compiling is het handig om een app of schil te hebben die eigenlijk de output van g++ in kleur zet, 'colorgcc' is een perl script. Hoe het juist werkt ed. kan je zelf even opzoeken, ik heb het nooit echt gebruikt.

Voor debugging van de app zelf heb ik wel al eens gespeeld met valgrind. Daarmee kan je zoeken of er memory leeks in je software zitten. Handig indien je een daemon of iets dergelijks aan het maken bent. (Buiten tools zoals gdb natuurlijk)

Klinkt idd handig, ik zal hier eens naar kijken :-)

kluyze schreef op zaterdag 24 oktober 2009 @ 23:21:
Verder lijkt het me gewoon handig dat je ergens iets doet met logging. Als ik iets wil debuggen in eender welke taal gooi ik er standaard een hoop printf's/echo's/System.out.println's/... tegen aan. Met eventueel een code in (bv 'DEBUG' + het lijnnummer, in c++ als ik me niet vergis met de macro '__LINE__). Eigenlijk vind ik dat zelf nog steeds de meeste snelle en simpele manier van debuggen.

Logging is idd een handige debug techniek, echter is dit niet echt taal specifiek (zoals je zelf al aangeeft) en uiteraard ben ik hier wel bekend mee :-)

[Memorice]

Olaf van der Spek schreef op zaterdag 24 oktober 2009 @ 23:41:
[...]

Ik zie dat als teken dat je niet weet hoe een echte debugger werkt.

Kun je dit eens uitleggen? Als ik jouw post lees, dan lees ik het als 'logging is overbodig wanneer je weet hoe je met een debugger moet omgaan', kortom het gebruik van een debugger is efficienter dan logging. Als dit idd je statement is, dan ben ik zeer benieuwd naar je onderbouwing, want dan kan ik in het vervolg misschien nog efficienter debuggen

Edit: Ik denk trouwens dat je er in sommige gevallen niet aan ontkomt om dingen te loggen, bijv. als bepaalde bugs pas ontstaan na dagen rekentijd of zelfs at random lijken op te treden.

[ Voor 14% gewijzigd door Memorice op 25-10-2009 00:02 ]

[kluyze]

Indien je gdb gebruikt dan is er een commando in linux waarmee je kan instellen dat er een core dump gedaan wordt. ulimit moet je maar eens opzoeken. Dan kan je in gdb nog terug vinden waar je app in de fout is gegaan.

@Olaf van der Spek: Hoezo. Omdat ik een logging de meest handige methode vind van debuggen, weet ik niet wat een debugger is? Met een variabele logging waar je dus ook debug code met een simpele variabele in een configfile mee kan aan- en uitzetten zegt in vele gevallen al heel veel. Daarvan wil ik ook wel wat meer weten waarom je dat vindt.

[ Voor 12% gewijzigd door kluyze op 25-10-2009 01:15 ]

[.oisyn]

Sorry, maar iets als "printf's/echo's/System.out.println's" zoals jij dat zei heeft weinig met logging te maken, en meer met wat men noemt "printf-debugging", wat met name door mensen wordt gebruikt die geen debugger tot hun beschikking hebben (veel PHP'ers zie je dat doen), of die er gewoon niet mee om kunnen gaan.

Logging daarentegen doe je niet met printf, echo of System.out.println maar met een framework (in C++ liefst in de vorm van een macro zodat je het makkelijk uit kunt zetten in final builds), waarbij je de log entries sowieso al van begin af aan in je code zet en niet pas als de boel mis gaat en je besluit eens te gaan debuggen.

En als je printf-debugging dan toch handiger vind heb je denk ik nooit op grote projecten gezeten waarin het toevoegen van een regel code en het recompilen zorgen voor een round-trip time van enkele minuten extra per keer, terwijl het zetten van een breakpoint en iets uitlezen uit een watch window velen malen sneller gaat en bovendien zelfs meteen in de huidige debug sessie kan. Goed, als je alternatief gdb is snap ik het wel, want dat is gewoon masochisme

[ Voor 25% gewijzigd door .oisyn op 25-10-2009 01:38 ]

[Erik Jan]

Onderzoek ook vooral de mogelijkheden voor remote debugging die je IDE en je target platform (het servercluster) je te bieden hebben. Dan hoef je tijdens het ontwikkelen niet naar archaïsche middelen als de gdb commandline te grijpen, waardoor je een heel stuk productiever kan werken.

Een goede voorbereiding is het halve werk, zeg maar. Ook m.b.t. logging

[NC83]

.oisyn schreef op zondag 25 oktober 2009 @ 01:34:
En als je printf-debugging dan toch handiger vind heb je denk ik nooit op grote projecten gezeten waarin het toevoegen van een regel code en het recompilen zorgen voor een round-trip time van enkele minuten extra per keer, terwijl het zetten van een breakpoint en iets uitlezen uit een watch window velen malen sneller gaat en bovendien zelfs meteen in de huidige debug sessie kan. Goed, als je alternatief gdb is snap ik het wel, want dat is gewoon masochisme

Eerlijk gezegd neem ik liever een TRACE("BLA"); macro dan een debugger voornamelijk als het runnen in debug een perfomance hit van 50x heeft, naast de hele compile tijd die een switch tussen dev en debug bevat, die meer is dan die enkele regel toevoegen en compilen.

[.oisyn]

Hoezo "de hele compiletijd", sinds wanneer zijn debug en release builds mutually exclusive? Die heb je toch gewoon naast elkaar staan? Switchen naar debug is dus niets meer dan het switchen van project config, en indien je nog geen changes hebt gemaakt hoeft er dus ook niets gecompiled te worden.

Daarnaast zou je optimizations ook gewoon lokaal uit kunnen zetten in bepaalde delen van de code.

[ Voor 14% gewijzigd door .oisyn op 25-10-2009 03:06 ]

[Olaf van der Spek]

MEMORICE schreef op zaterdag 24 oktober 2009 @ 23:45:
Een cluster met 50 servers, 8 cores en 8 GB RAM per server en het OS is Ubuntu.

Dan is cmake dus wel beschikbaar. Is Ubuntu ook je dev omgeving? Want daar heb je eigenlijk nog niks over gezegd, ik gebruik gewoon Windows en VS om Linux (web) services te ontwikkelen.

MEMORICE schreef op zaterdag 24 oktober 2009 @ 23:48:
Kun je dit eens uitleggen? Als ik jouw post lees, dan lees ik het als 'logging is overbodig wanneer je weet hoe je met een debugger moet omgaan', kortom het gebruik van een debugger is efficienter dan logging. Als dit idd je statement is, dan ben ik zeer benieuwd naar je onderbouwing, want dan kan ik in het vervolg misschien nog efficienter debuggen

Met een debugger kun je watches gebruiken en daarmee kun je veel meer zien dan met printf. Het is gewoon veel eenvoudiger.
Logging is natuurlijk niet (altijd) overbodig, maar logging is iets anders dan debugging.

[Zoijar]

Ik gebruik ook bij voorkeur "printf" debugging. Veel makkelijker en sneller vaak. Even snel kijken waar een fout zit door gewoon te printen na alles dat lukt. Zeker als je bijvoorbeeld 4 threads hebt die communiceren, dan kan je er niet zo makkelijk even doorheen stappen met een debugger.

[NC83]

.oisyn schreef op zondag 25 oktober 2009 @ 03:04:
Hoezo "de hele compiletijd", sinds wanneer zijn debug en release builds mutually exclusive? Die heb je toch gewoon naast elkaar staan? Switchen naar debug is dus niets meer dan het switchen van project config, en indien je nog geen changes hebt gemaakt hoeft er dus ook niets gecompiled te worden.

Daarnaast zou je optimizations ook gewoon lokaal uit kunnen zetten in bepaalde delen van de code.

Bij ons is dat niet door een config optie en wij hebben 5 build settings die niet tegelijkertijd lokaal gebuild worden. Het ligt er trouwens aan wat er gedebugged moet worden voor die TRACE call, als het een data structuur is dan is een TRACE schrijven wel een beetje veel en werkt de debugger natuurlijk veel sneller.

[Memorice]

Olaf van der Spek schreef op zondag 25 oktober 2009 @ 08:52:
[...]

Dan is cmake dus wel beschikbaar. Is Ubuntu ook je dev omgeving? Want daar heb je eigenlijk nog niks over gezegd, ik gebruik gewoon Windows en VS om Linux (web) services te ontwikkelen.
[...]

Ja, Ubuntu is ook mijn dev omgeving.

[MSalters]

Zoijar schreef op zondag 25 oktober 2009 @ 09:48:
Ik gebruik ook bij voorkeur "printf" debugging. Veel makkelijker en sneller vaak. Even snel kijken waar een fout zit door gewoon te printen na alles dat lukt. Zeker als je bijvoorbeeld 4 threads hebt die communiceren, dan kan je er niet zo makkelijk even doorheen stappen met een debugger.

Bekende vergissing. printf() heeft vrijwel altijd een mutex, om te voorkomen dat twee stukken tekst door elkaar komen . Daardoor introduceer je (alleen in debug) synchronisatie tussen threads. Met een beetje pech lost dat net een deadlock of raceconditie op, zonder dat je het door hebt.

[roy-t]

Zoijar schreef op zondag 25 oktober 2009 @ 09:48:
Ik gebruik ook bij voorkeur "printf" debugging. Veel makkelijker en sneller vaak. Even snel kijken waar een fout zit door gewoon te printen na alles dat lukt. Zeker als je bijvoorbeeld 4 threads hebt die communiceren, dan kan je er niet zo makkelijk even doorheen stappen met een debugger.

Tsja zoals .Oisyn al zei: printf invoegen en sensible waarden uitprinten en dan recompilen versus "klik breakpoint" waarna je kan stappen en van alles de waardes kunt zien.

Laatste is over het algemeen toch mijn voorkeur en vele malen sneller. (hoewel ik vooral voor kleine java projectjes vaak even een 'println' ergens wil neerpleuren .

[Zoijar]

MSalters schreef op maandag 26 oktober 2009 @ 10:07:
Bekende vergissing. printf() heeft vrijwel altijd een mutex, om te voorkomen dat twee stukken tekst door elkaar komen . Daardoor introduceer je (alleen in debug) synchronisatie tussen threads. Met een beetje pech lost dat net een deadlock of raceconditie op, zonder dat je het door hebt.

Ik ben me bewust van de side-effects; ik gebruik zelfs een eigen log dat expliciet locked. Niettemin is het een ontzettend handig hulpmiddel.

roy-t schreef op maandag 26 oktober 2009 @ 11:39:
Tsja zoals .Oisyn al zei: printf invoegen en sensible waarden uitprinten en dan recompilen versus "klik breakpoint" waarna je kan stappen en van alles de waardes kunt zien.

Laatste is over het algemeen toch mijn voorkeur en vele malen sneller. (hoewel ik vooral voor kleine java projectjes vaak even een 'println' ergens wil neerpleuren .

Als je een beetje weet wat er waar fout gaat. Als je in een virtuele wereld rondloopt en bij bepaalde handelingen wordt er een muur ineens even zwart is het een stuk lastiger. Zeker als dat asynchrone updates zijn uit andere threads en er state op je GPU staat en niet direct in geheugen. Het zal allemaal wel kunnen, maar ik vind het ook nog steeds lastig om een matrix stack in een debugger uit te lezen. Ik print dan liever wat (uitgebreidere) info. Ik gebruik ook soms wel een debugger, maar de meeste fouten spoor ik op door extended log informatie te bekijken en dan te denken "hey, that's funny". Re-compile is ook vaak maar 1 implementatie file en een link. Toegegeven, mijn projecten bestaan meestal niet uit meer dan enkele duizenden regels en enkele tientallen files; wellicht zijn er andere dingen nodig als je het over honderden files en een miljoen regels hebt. (maar er werd zo neerbuigend gedaan over "printf debugging", terwijl het een handig hulpmiddel is dat veel programmeurs eens goed zouden moeten gebruiken voordat ze allemaal ingewikkelde debug dingen gaan doen )

[ Voor 60% gewijzigd door Zoijar op 26-10-2009 11:49 ]

[.oisyn]

Zoijar schreef op maandag 26 oktober 2009 @ 11:39:
Als je een beetje weet wat er waar fout gaat. Als je in een virtuele wereld rondloopt en bij bepaalde handelingen wordt er een muur ineens even zwart is het een stuk lastiger. Zeker als dat asynchrone updates zijn uit andere threads en er state op je GPU staat en niet direct in geheugen.

Daar heb je weer andere debugger tools voor, zoals bijv. Pix for windows voor D3D debugging

Het zal allemaal wel kunnen, maar ik vind het ook nog steeds lastig om een matrix stack in een debugger uit te lezen. Ik print dan liever wat (uitgebreidere) info.

Ik heb niet zoveel ervaring met andere debuggers, maar in MSVC++ kun je bijv. in een filetje (autoexp.dat) per type aangeven hoe en wat er weergegeven moet worden in de debugger (en daar ook visualizers voor programmeren). Daarnaast kun je vanuit de debugger handmatig (parameterloze) functies en methods aanroepen, wat je weer kunt gebruiken om op commando extra informatie over een instance naar de tracelog te schrijven.

(maar er werd zo neerbuigend gedaan over "printf debugging", terwijl het een handig hulpmiddel is dat veel programmeurs eens goed zouden moeten gebruiken voordat ze allemaal ingewikkelde debug dingen gaan doen )

Tja, sorry, maar ik blijf het zien als de meest primitieve vorm van debugging die meestal meer tijd kost dan de alternatieven

[roy-t]

Zoijar schreef op maandag 26 oktober 2009 @ 11:39:
[...]

Ik ben me bewust van de side-effects; ik gebruik zelfs een eigen log dat expliciet locked. Niettemin is het een ontzettend handig hulpmiddel.


[...]

Als je een beetje weet wat er waar fout gaat. Als je in een virtuele wereld rondloopt en bij bepaalde handelingen wordt er een muur ineens even zwart is het een stuk lastiger. Zeker als dat asynchrone updates zijn uit andere threads en er state op je GPU staat en niet direct in geheugen. Het zal allemaal wel kunnen, maar ik vind het ook nog steeds lastig om een matrix stack in een debugger uit te lezen. Ik print dan liever wat (uitgebreidere) info. Ik gebruik ook soms wel een debugger, maar de meeste fouten spoor ik op door extended log informatie te bekijken en dan te denken "hey, that's funny". Re-compile is ook vaak maar 1 implementatie file en een link. Toegegeven, mijn projecten bestaan meestal niet uit meer dan enkele duizenden regels en enkele tientallen files; wellicht zijn er andere dingen nodig als je het over honderden files en een miljoen regels hebt. (maar er werd zo neerbuigend gedaan over "printf debugging", terwijl het een handig hulpmiddel is dat veel programmeurs eens goed zouden moeten gebruiken voordat ze allemaal ingewikkelde debug dingen gaan doen )

Tsja printf-debugging is gewoon een van die tools die je hebt, ik maak me er ook wel eens 'schuldig' aan, maar ik dacht dat je echt als voordeel van printf wilde benadrukken "ff debuggen" terwijl een breakpointje eigenlijk veel sneller is (en meer info geeft).

Maar natuurlijk is het een handig tool, bijvoorbeeld als je tijdens het runnen van het programma gewoon nog ergens de output in de gaten wilt houden, zonder het programma elke keer te pauzeren. (*bijvoorbeeld rare case bugs*). Natuurlijk zijn er dan ook weer conditional breakpoints enzo, maar die gebruik ik eerlijk gezegt niet.

[Zoijar]

.oisyn schreef op maandag 26 oktober 2009 @ 12:30:
Daar heb je weer andere debugger tools voor, zoals bijv. Pix for windows voor D3D debugging

Ja, of glslDevil of gDEBugger, die gebruik ik ook nog wel eens. En valgrind uiteraard.

Ik heb niet zoveel ervaring met andere debuggers, maar in MSVC++ kun je bijv. in een filetje (autoexp.dat) per type aangeven hoe en wat er weergegeven moet worden in de debugger (en daar ook visualizers voor programmeren). Daarnaast kun je vanuit de debugger handmatig (parameterloze) functies en methods aanroepen, wat je weer kunt gebruiken om op commando extra informatie over een instance naar de tracelog te schrijven.

[...]

Tja, sorry, maar ik blijf het zien als de meest primitieve vorm van debugging die meestal meer tijd kost dan de alternatieven

Misschien is het ook luiheid van mijn kant Een keer goed je debugger customizen zal wel veel helpen. Nou komt het ook voort uit het gebrek aan goede debugger guis onder linux vroeger; onder windows gebruikte ik altijd gewoon meteen de visual studio debugger. Maar tegenwoordig onder eclipse is de debugger ook wel behoorlijk; toch eens wat vaker naar kijken dan.

roy-t schreef op maandag 26 oktober 2009 @ 12:38:
Tsja printf-debugging is gewoon een van die tools die je hebt, ik maak me er ook wel eens 'schuldig' aan, maar ik dacht dat je echt als voordeel van printf wilde benadrukken "ff debuggen" terwijl een breakpointje eigenlijk veel sneller is (en meer info geeft).

Punt bij mij is vaak dat je niet weet waar je een breakpoint zou moeten zetten, dus dan moet je overal doorheen (soms overheen) steppen. Dan step je weer net over de echte fout heen, en dan weer opnieuw... resources laden duurt vaak heel lang in debug... maar debugger zijn wel handig op z'n tijd. Ik vind het vaak een beetje te low-level; ik heb liever (eerst) wat informatie op hoger niveau.

Ach, het beste is gewoon geen fouten maken

[ Voor 24% gewijzigd door Zoijar op 26-10-2009 12:52 ]

[.oisyn]

Zoijar schreef op maandag 26 oktober 2009 @ 12:49:
Punt bij mij is vaak dat je niet weet waar je een breakpoint zou moeten zetten, dus dan moet je overal doorheen (soms overheen) steppen. Dan step je weer net over de echte fout heen, en dan weer opnieuw...

Daar heb je breakpoint hit counts voor . Wat ik in MSVC++ vaak doe is een breakpoint ergens zetten met een hitcount constraint op heel hoog (zodat hij wel telt maar niet breakt), en als de fout dan optreedt kun je direct zien wat de hit count voor die ene breakpoint is. Voor de volgende run stel je voor die breakpoint dan in bij welke hit count hij moet breaken. Maar dit werkt natuurlijk alleen in situaties die geheel deterministisch zijn, wat voor multithreaded code soms lastig is (hoewel het wel enorm scheelt om in je app mogelijkheden te hebben om je multithreaded code geheel deterministisch uit te laten voeren)

[NC83]

Zoijar schreef op maandag 26 oktober 2009 @ 12:49:
[...]

Ja, of glslDevil of gDEBugger, die gebruik ik ook nog wel eens. En valgrind uiteraard.

[...]

Misschien is het ook luiheid van mijn kant Een keer goed je debugger customizen zal wel veel helpen. Nou komt het ook voort uit het gebrek aan goede debugger guis onder linux vroeger; onder windows gebruikte ik altijd gewoon meteen de visual studio debugger. Maar tegenwoordig onder eclipse is de debugger ook wel behoorlijk; toch eens wat vaker naar kijken dan.


[...]

Punt bij mij is vaak dat je niet weet waar je een breakpoint zou moeten zetten, dus dan moet je overal doorheen (soms overheen) steppen. Dan step je weer net over de echte fout heen, en dan weer opnieuw... resources laden duurt vaak heel lang in debug... maar debugger zijn wel handig op z'n tijd. Ik vind het vaak een beetje te low-level; ik heb liever (eerst) wat informatie op hoger niveau.

Ach, het beste is gewoon geen fouten maken

ALs je er over heen stept kun je natuurlijk altijd je instruction pointer terug plaatsen

[Zoijar]

NC83 schreef op maandag 26 oktober 2009 @ 13:17:
ALs je er over heen stept kun je natuurlijk altijd je instruction pointer terug plaatsen

Nee, helaas is je state dan iha niet meer hetzelfde.

[farlane]

Hmm, gebruik het vrij vaak om te bepalen waar je een breakpoint moet plaatsen, en voor embedded spul wil het nog wel eens voorkomen dat een debugger niet werkt omdat je target in een of andere sleepmode gaat tussendoor oid.

Anyways, voor mij is het nog steeds een onmisbare skill.

[Olaf van der Spek]

Zoijar schreef op maandag 26 oktober 2009 @ 12:49:
Punt bij mij is vaak dat je niet weet waar je een breakpoint zou moeten zetten, dus dan moet je overal doorheen (soms overheen) steppen. Dan step je weer net over de echte fout heen, en dan weer opnieuw... resources laden duurt vaak heel lang in debug... maar debugger zijn wel handig op z'n tijd. Ik vind het vaak een beetje te low-level; ik heb liever (eerst) wat informatie op hoger niveau.

Je weet niet waar de breakpoints moeten maar wel waar de printfs moeten? Dat is toch niet logisch?
PHP debugging doe ik ook met 'printf' en daarom heb ik er een gruwelijke hekel aan. Ten opzichte van een debugger is het gewoon zo irritant.

[ Voor 10% gewijzigd door Olaf van der Spek op 27-10-2009 16:47 ]

[farlane]

Olaf van der Spek schreef op dinsdag 27 oktober 2009 @ 15:43:
[...]

Je weet niet waar de breakpoints moeten maar wel waar de printfs moeten? Dat is toch niet logisch?
PHP debugging doe ik ook met 'printf' en daarom heb ik er een gruwelijke hekel aan. Ten opzichte van een debugger is het gewoon zo irritant.

Volgens mij bedoelt hij ook dat hij mbv printf's de flow probeert te achterhalen, zodat je daarna weet waar je het breakpoint zou moeten plaatsen. Klinkt toch niet zo gek?

[TheGrandWazoo]

Olaf van der Spek schreef op dinsdag 27 oktober 2009 @ 15:43:
[...]

Je weet niet waar de breakpoints moeten maar wel waar de printfs moeten? Dat is toch niet logisch?
PHP debugging doe ik ook met 'printf' en daarom heb ik er een gruwelijke hekel aan. Ten opzichte van een debugger is het gewoon zo irritant.

Als je er zo'n hekel aan hebt zou je eens kunnen kijken naar Xdebug of DBG en een ondersteunende IDE (Netbeans, Eclipse, Aptana, Komodo, etc.). Scheelt zeker enorm veel frustraties en gekloot met 'var_dump', 'printf' en 'echo' .