3 ms·
I would add to this: 1. Visual Studio debugger is really, really good and you should use it to step through your program (or equivalent IDE based workflow). 2
by fsloth 4y ago
I would add to this:
1. Visual Studio debugger is really, really good and you should use it to step through your program (or equivalent IDE based workflow).
2. Learn to compile your code with memory safeguards and use the tooling around them. Specific depends on the platform. On POSIX address sanitizer is good I hear. On Windows you can use the debug CRT and gflags to instrument your binary really well.
- rahen 4y agoBesides Visual Studio (the Windows IDE, not VS Code), QT Creator also has an excellent debugger. Probably the best open source and cross platform C/C++ IDE around.
- Sohcahtoa82 4y agoPeople should be using IDEs with modern debuggers anyways. Being able to step through your code one line at time and instantly see the values of all your variables is going to be FAR more effective than adding a bunch of print statements, no matter what language you're using. It always blows my mind to hear about how many engineers don't know how to use their IDE's debugger and don't know what a breakpoint is.
- fsloth 4y agoPerhaps there is not enough training available on these tools. Raw terminal GDB also is not very user friendly so if someone has experience from that it might be a disencouragement.
- Sohcahtoa82 4y agoIt really should be a standard part of any school curriculum, book, website, or any other media that people consume to learn programming. Debugging is such an integral skill to software engineering that it's beyond inexcusable that it's not taught. Graphical debuggers aren't even hard to use. You can learn PyCharm's in an hour. Learn how to set a break point, examine local variables, learn the different step buttons, and view the function call stack and the local variables at each level of the stack. Heck, maybe people wouldn't struggle with recursion so much if they were taught how to examine the call stack using the debugger, showing what happens when function A calls B which calls C, examine the local variables at each level of the stack, including an example where A and B both have a local variable called "x", and then note that function A calling itself is not a special case and adds another level to the stack with a new "x". Without knowing how to use a debugger, learning to program feels like programming a black box. Sure, a bunch of "print" statements help, but nothing beats stepping through code line-by-line.