>So, what is the good and effective debugging?
Compile with the -g flag and run gdb (or a GUI interface to gdb like DDD or Eclipse's CDT) on the executable.
>So, what is the good and effective debugging?
Compile with the -g flag and run gdb (or a GUI interface to gdb like DDD or Eclipse's CDT) on the executable.
> So, what is the good and effective debugging?
For memory debugging, using the tools I suggested. Test as you go, so that you spot early on any overwrites or memory leaks.
Also consider tools like lint which perform static analysis on the code to spot bugs.
For memory allocations, try and create wrapper functions to allocate, extend and free, and very carefully debug them in isolation before integrating them into the main project.
Also, keep such code very simple - it's all too easy to outsmart yourself when dynamically allocating and freeing stuff.
For example, I often allocate memory then go and figure out all the places where the free should happen, and make sure it does before complicating matters further.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I used KDevelop with GDB debugger. What I did in debugging was only looking at the values of each variables. I didn't even use assert and try-catch-throw whatsoever. I don't have any experience with them. Maybe that's one of my faults.
So, when the debugger showed the memory allocation or any assembly lines, I don't know how to read them. That's one more of my weaknesses. Can you help me understand them?