I don't always have access to an integrated debugger, so sometimes I need to get down and dirty with the logs to figure out what's not working correctly.
I'd often end up staring at pages and pages of, er.. umm, well.. stuff like this when debugging Vector3D :
x=0.3,y=0.7,z=3.9
x=0.7,y=1.7,z=0.2
x=2.1,y=0.2,z=0.2
x=4.3,y=0.1,z=4.1
Along the way I picked up a few techniques to accelerate the process. But first, I'll let the code speak for itself:
Lets take the constructor example. When you use this style (the default), you would get the following in your output window:
Vector3D vector3D(0.3f,0.7f,3.9f);
Vector3D vector3D(0.7f,1.7f,0.2f);
...
We can immediately copy and paste this from the log/output window straight back into the code window, hit recompile, and recover a dormant state from the past, ready for closer examination in the debugger.
The excel format is handy too, just copy and paste the output into excel, select any two columns, and hold the graph button. (scatter-XY is my favorite) You now have a visual representation of your vectors in less than 2 seconds.
More generally, this falls under the topic of code-which-generates-output-for-the-input-of-another-program. In this case, the c++ compiler itself. I'll have a lot more to talk about this topic in the posts to come.
But this example does raise one interesting special case, that of generating output, which is then fed back in as input to the same generating program. As we all know from control theory, we need a little extra work to avoid runaway feedback in this case!
Do you connect your output to your input? Let me know in the comments below!
No comments:
Post a Comment