Debugging
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
How do you guys go about debugging code? I learned how to program with VC++ and it had a very useful, powerful debugger. Later on I learned C and now I just use printing functions even when using huge IDEs. I think it's a bad habit but I'm just used to it.
>>55583955
idk, i learned python first and i didn't debug shit at all besides playing with it in the repl, now working with c++ it's a huge confusing mess.
>>55583955
Not a bad habit so far as I'm concerned. It's an excellent way to debug. Hell, I say you're an idiot if you're trying to make something work and you don't do this.
Probably a mixture of print statements, using step-into, break points and looking at the variables in memory at the point in question.
>>55583984
Breakpoints and watches are faster, safer, and more professional
>>55583996
Don't forget the call stack. Helps to figure out what called what.
>>55583955
Whatever works but I like debuggers better. Its nice to step through code line by line to see if it works like you think it should.
C-u C-M-xwhen I'm messing arround with emacs lisp and I don't know where I have a problem with my code.
>>55584226
In my experience prints are faster/more comfortable for finding out where things are going wrong
the actual debugger is good for finding out what is going wrong
though valgrind can help with the first aswell, if some memory stuff is going wrong.
>>55583955
I use printing too, but when something really fucks up, I use the VS debugger. It's really nice.
Pretty much all compiled languages have an excellent CLI debugger by this point.
printf
>>55589272
>my exp
i have used valgrind myself once. Did wonders to help a weird issue for me. Still need to learn how to use it better
>>55583955
Debugger 80% of the time, but in some special cases I like to use some writeline or Message.Show()
I connect to QEMU with gdb because operating systems.
Also printing stuff to serial console.
>>55583955gdb a.out
b _start
layout r
run
stepi
unless you're too retarded to read assembly
Mostly printf's, but if it's a crash bug then I'll usually go straight for GDB.
printk(), dump_stack(), md
printfs are good but you have to compile and run a lot of times.
I use gdb. At first it's hard but eventually you get the hang of it and learn to know where to look.
get error - go to the reported line and fix error
get weird error without linenumber - add a bunch of prints to narrow down where shit goes wrong
no idea what debuggers or breakpoints are but i doubt it would have saved me even half an hour in total so far. Is it worth spending more than half an hour looking into it? Is it some built in language feature or IDE-specific stuff that basically automates inserting printfs?
