I debug using printf. The supposed advantage of using a debugger is rapidly examining the state of the program. But the debugger offers no means of actually e

I debug using printf. The supposed advantage of using a debugger is rapidly examining the state of the program. But the debugger offers no means of actually examining anything other than the simplest variables. With printf, I can create a comprehensive presentation of that state that allows me to understand what the program is doing. A debugger is great when there's a diffuclty understanding the control flow (Where is the program crashing? How do we get there?). But as far as examining the state in a way one can easily parse - the debugger won't do that for you. With printf, you create an annotated story of the execution, showing you both the data and what it means. Example: Polygon count: 5 Polygon orientations: {A: pos, B: pos, C: pos, D: neg, E: pos} Centroids: {A: [0, 0], B: [20, 3], C: [7, -1], D: [5, 1], E: [2, 3]} Box bounds: {X: [-10, 10], Y: [-2, 4]} Polygons with centroid in box: {A, C, E} Looking at this output tells you what's wrong with the function that filters polygons with a centroid-in-box query (it doesn't handle negatively oriented polygons correctly). Sure, you can set up your watch variables to present information in that way... but then you're just doing printf with extra steps.