Debugging
Over a week ago, I installed Microsoft's VisualC++ Studio 2010. Microsoft provide a free version of their compiler for Windows applications that can be used by hobbyists and students. It's useful for learning how to code or creating free applications.
I used it to crank up Free Orion, the open source Masters of Orion game I wrote a patch for. It turned out that it compiled fine, but it crashed on startup, with no visible error message. So I tried using the MSVC debugger.
I've never used debuggers before. I've never really seen the point. Most apps I've written or used mean that I have control over the source code. If something crashes, I put print statements all over the code until I work out where the bugger is crashing. In the main it works, although it starts to fail when it takes a while for something to recompile properly, the project is big and I don't necessarily have access to change the source code.
The MSVC debugger is quite fun. You can start an instance of your program and you can step through each statement statement of the code in the execution. You can step deeper into the execution, step over or step out of the execution. So for example, if you have a function, stepping into it takes you into the start of the function. Stepping over it executes the whole function. If you step into the function and then get bored going through it, stepping out takes you past the function's end. It's pretty neat, and great for isolating errors. It's also fun as I get to see everything that the program is doing.
Not only can I see it running code I've written, but I can see it running code I haven't that's handled for me, like copy and assign operations, as well as watch the assembly code execution of functions like malloc and free. It's not really useful to fixing or debugging anything, but it's fun and expands my knowledge of programming.
I've also learned to use breakpoints. This is a system where you click in the code and say "stop here". This got useful as I stepped through the execution and got quite far in before it crashed (the crash happened on the third function of main, so it felt like I was making progress, but this was illusory, as that function is basically the whole initialise and run the game loop function). I could find functions where the crash happened and then set up a breakpoint and come back to it later.
I also found the problem, incidentally, which happened to be a problem with OpenAL (the sound part of the game). It failed to work because only the latest libraries are compatible with Windows 7, and the "What went wrong?" function returned a null pointer, which the logger crashed on when trying to tell me about it.
I used it to crank up Free Orion, the open source Masters of Orion game I wrote a patch for. It turned out that it compiled fine, but it crashed on startup, with no visible error message. So I tried using the MSVC debugger.
I've never used debuggers before. I've never really seen the point. Most apps I've written or used mean that I have control over the source code. If something crashes, I put print statements all over the code until I work out where the bugger is crashing. In the main it works, although it starts to fail when it takes a while for something to recompile properly, the project is big and I don't necessarily have access to change the source code.
The MSVC debugger is quite fun. You can start an instance of your program and you can step through each statement statement of the code in the execution. You can step deeper into the execution, step over or step out of the execution. So for example, if you have a function, stepping into it takes you into the start of the function. Stepping over it executes the whole function. If you step into the function and then get bored going through it, stepping out takes you past the function's end. It's pretty neat, and great for isolating errors. It's also fun as I get to see everything that the program is doing.
Not only can I see it running code I've written, but I can see it running code I haven't that's handled for me, like copy and assign operations, as well as watch the assembly code execution of functions like malloc and free. It's not really useful to fixing or debugging anything, but it's fun and expands my knowledge of programming.
I've also learned to use breakpoints. This is a system where you click in the code and say "stop here". This got useful as I stepped through the execution and got quite far in before it crashed (the crash happened on the third function of main, so it felt like I was making progress, but this was illusory, as that function is basically the whole initialise and run the game loop function). I could find functions where the crash happened and then set up a breakpoint and come back to it later.
I also found the problem, incidentally, which happened to be a problem with OpenAL (the sound part of the game). It failed to work because only the latest libraries are compatible with Windows 7, and the "What went wrong?" function returned a null pointer, which the logger crashed on when trying to tell me about it.