Дебъгване с printf или hell on earth...

Може ли да се избегне този вид дебъгване? Аз лично съм забелязал че при дебъгване на всякакъв код, свързан с dispatch-ване на съобщения и дублиращи се и разпиляни логики просто това е начина. Знам че и при multithreaded приложенията се ползва с успех. Да не говорим за скриптове, не разполагащи с дебъгер. Но понякога е много досадно

Има ли някой опит в заобикалянето/заменянето му с друга по-продуктивна техника?

The ones who live by the sword get shot by the ones who don't.

Ako niakoi izmisli nachin za towa i na men shte mi e interesno da go chuia (CW pod OSX wse oshte niama normalno rabotesh debugger i kato triabwa da si tyrsia lainata w 300k reda cod malko se raztreperwam :( ).

kakyv e problema na printf? zabeliazwam che wse po-chesto polzwam tozi metod, wmesto convenciolanlia.

skoro popadnah na towa mnenie ot Rob Pike i Brian Kernighan (nadiavam se che niama nujda da kazwam koi sa :):

As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated dta structures and control flow; we find stepping through a programm less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient.

ako printf() - ti e dostatuchno burz da :)

na njakoi ustroistwa - printf() trjabwa da se podade ot host mashinata do kit-a, kit-a da otvurne che e priel (i toj ne priema winagi ami na opredeleni cikli)... Obiknowenno na dreamcast edin printf() otnemashe kum 0.2-0.3 sekundi.

za predpochitane beshe debugwaneto ili printf() kojto pechata na monitora (TV-to) - wmesto na consolata (monitora na PC-to)...

ama se swikwa :)

Oshte edna prostotia kogato izpolzwash printf() standartnite funkcii e che te nulirat grehskite w matematicheskata biblioteka (math exceptionite)... Za edna tupa racing igra kojato pisahme za PSX imahme tozi problem (njamahme oficialnia dev-kit - shefa ni se beshe skupil i nikakuv debuger za nas)

sus printf() raboteshe wsichko normalno, mahash printf() i se skapwa... Nie izpolwahme softwarena emulatzia na float-point za njakoi drebni no sushtestweni smetki - i tam se okapwashe.. I tuj kato imahme printf() mezhdu redovete rabotata raboteshe - ama w release nema printf() i ne raboti .... i se nalagashe sami da si chistem math-exceptionite... No naistina problema beshe che sus printf() se bjahhme podlugali che wsichko raboti... Razbira se tova e stranichen efekt - printf() wuobshte mozheshe da bude napisan po-kulturno - ama nejse - standartni gcc-biblioteki...

Njakoi gledal li e dali printf()-a (vsprintf()?a) za MSVC CRT-to chisti math-exceptionite i natrupanite greshki?

tirulirutatuutuu

edno neshto koeto nie izpolzwame e wseki programist da si ima predefinirana funckia (po-skoro makros) za pechatane naprimer az imam

MALKIA_PRINT( eDC_SOUND, "Invalid sfx %d", feSfxAcceptButton );

ili ako e za memory managera

MALKIA_PRINT( eDC_MEMD, "Invalid memory block at: %p", ptr );

taka purwo samo az si gledam ot pechatite, i oshte ako rabotja po poveche ot edin modula (zwuk, memory manager, pad-controlite) - togava i kategoria izpolzwam i moga da si ja prewkluchwam...

w momenta e malko problem - tuj kato za minalia proekt sam pravih audioto - no sega doide i oshte edin programist da mi pomaga i sega trjabwa malko da smenim politikata inache trjabwa postojanno da pisha za da wizhda i toj...

MALKIA_PRINT( eDC_SOUND, "Invalid sfx %d", feSfxAcceptButton );
LYDON_PRINT( eDC_SOUND, "Invalid sfx %d", feSfxAcceptButton );

w ponedelnik shte se razbere - kvo e reshil nashia glaven po toz wurpos.

mozhe da minen na neshto ot roda

PRINT( USER_MALKIA+USER_LYDON, eDC_SOUND, "Invalid sfx %d" );

njakoi da ima idei?

tirulirutatuutuu

Мда, инересно мнение не се бях замислял...
То аз преди малко наистина много лесно намерих така един bug, който го гоних вчера цял ден с трасиране... и не си взех поука сам, ехх
Мерси за цитата, явно по времето на K&R вече е имало и дебъгери

The ones who live by the sword get shot by the ones who don't.

При нас имаме едни #pragmi дето printiat в Output прозореца на MSVC-то като компилира, за да можеш като click-неш на съответното съобщение да те закара на файла и реда дето е написано. Нещо такова е:

#pragma todo( Zemedelec, "Clear that mess!")
или
#pragma fixme( Zemedelec, "Just make it work somehow..")

и съответно на всяка машина локално има един файл username.h където има:

#undef __ALL_USERS_
#define __USER_ZEMEDELEC_

или нещо такова...
Това е compile-time както виждаш, никакъв проблем да се направи и runtime де, интересното е дали да се направи с macros (сменяш user-a и целия проект се прекомпилира, но е max бързо) или се check-ват текущо активните user-и (което e малко по-бавно, но позволява те да се сменят дори по време на изпълнение/дебъг).
За runtime обаче ползваме Output-a на MSVC който понякога не загрява и е бъгав нещо, ама така е като си нямаме in-game такава

The ones who live by the sword get shot by the ones who don't.

ne sum probval s takiva #pragmi pod CodeWarrior-a ili GCC-to - za MSVC-to widjah che directx8 specific koda kojto sa pisali gi izpolzwa - ama nie ne mozhe da si pozwolim - inache izglezhda jako.

pri nas po skoro slagame

// TODO: Alabala
// FIXME: ddd

pri nas sushto imame local_user.h :) - a inache bih iskal ako e wuzmozhno wsichko da pechati w ekrana na MSVC-to - ame ne moe :) - ili pone doosta rabota bi otnelo - po princip mozhe da se pishat razni plugini ili biblioteki za upravljawane na hosta - ame e izlishna rabota (pone zasega)

Wsushnost minahme na local_user.h - zashtoto CodeWarriora ne mozheshe da se setwa w sredata razni environment promenlivi - wupreki che ako wikame komandnia kompilator mozhe....

tirulirutatuutuu

Ima.
Dobavi prenasochvane na izhoda, grep, tail i etc. podobni prostotiyki i stava mnogo po-produktivno.

In All cases

Njama nachin da se izbegne. Towa si e dokazan metod.
Bugowete sa tolkova razlichni, che de da imashe universalna recepta za tyrseneto im.
Log files, asserts, smart pointers, stack checks (/GS like), e.t.c. pomagat -- obshto wzeto defanziwno programirane. Samo che w edin moment cenata stawa mnogo wisoka.

BTW printf-a ot MSVCRT e neopisuemo bawen. ne moga da si objasnja kak sa go postignali. absolutno straightforward rewrite deto poddyrzha samo neshtata deto gi polzwame (%s, %d, %g) se okaza neshto kato 10-11 PYTI po-byrz... ta taka - ako mnogo printite, mozhe da wi se okazhe polezno da go prenapishete. (Heheh, kyde e onja sladur deto wdigashe para za bezsmislenoto prenapiswane predi dwa-tri dni...)

inache - spored men wsichki reshenija koito zapochwat s "wseki programist si ima..." sa stypka po edno mnogo dylgo, strymno i hlyzgawo nanadolnishte... slozhish #pragma todo(Skotowydec, "twa da go oprawja"), razboljawash se za tri dni i builda zaminawa pri klienta s njakakwa newerojatno typotija, shtoto tam kydeto sa go kompilirali ne pishelo da se obazhda za twoite todo-ta.

---
Bingo! Bongo! I don't want to leave the Kongo!

a za konzolite - nekwi hora razprawjat che istinata e da ti wyrwi web server na konzolata i tam da razprawja kwo stawa s neja... za po-realtime neshta ne stawa, no inache mozhesh da servirash mnogo po-bogata informacija ot edin printf (ili ot kakwoto mozhesh da syberesh na low-res telewizora). To da se integrira edin webserver ne e koj znae kakyw zor - primerno ima edin GoAhead deto e za takiwa celi i e free.

---
Bingo! Bongo! I don't want to leave the Kongo!

Аз си хвърлям целия дебъг output към някой TCP порт на някое IP. Много е удобно щото хем мога да си пиша windows-кия софт под windows, хем разглеждането на дебъг информацията ми върви под Linux на друг монитор. Отделно че разните unix-ки филтри са много удобни.

Не винаги можеш да го правиш това, поне не винаги е 'сполучливо'...
Например в една игра понякога е трудно да направиш unit test!
Да не говорим че ако сменяш контролните параметри на някакъв алгоритъм всички unit test-ове зависещи от него се прецакват и трябва да ги поддържаш...
Например аз имах един epsilon на едно място дето като го увеличих 10 пъти (стана 0.0001) и мнооого неща вече ня бяха съвсем същите (някои не работеха). А промяната си беше нужна! И какво - да се занимавам с поддръжка на 7-8 unit test-а?... де да знам...

The ones who live by the sword get shot by the ones who don't.

> И какво - да се занимавам с поддръжка на 7-8 unit test-а?
Da, sam si poluchil d-vo za polzata.

Az si napravih slednoto neshto:
malyk lib za multithreaded in-memory log-vane v circular fixed size buffer, nikakvi sinhronizirashti primitovi osven InterlockedIncrement (koeto e edna mashinna instrukcija de-fakto 'lock inc dword ptr [neshto-si]' - njama kernel mode transitions, nema giavol) PLUS debugger extension za dump-vane na contents na in-memory-log bufera. Razbira se, debuggera moje da byde punsat na remote machina ili dori pod kernel debugger.

T'va e samo za win platformi, ov korz. Inache za java aplikacii reshenija dal gospod
Btw, sorsovete mi sa available upon request (tovaren_mail@yahoo.com)