4 ms·

This Raymond Chen guy should probably look into what debuggers are available on his platform of choice, he could save time by avoiding all this printf() style d

by tveita 3y ago

This Raymond Chen guy should probably look into what debuggers are available on his platform of choice, he could save time by avoiding all this printf() style debugging.

l33t233372 3y ago
Printf style debugging is very nice. I like it more than actually using the debugger in a lot of cases.
yowlingcat 3y ago
Why is printf() style debugging supposed to be a bad thing if done properly? Are you of the opinion that one is supposed to use either/or of these approaches rather than using each approach for different situations to supplement each other?
kragen 3y ago
for context, raymond wrote significant parts of windows going back to the 80s, and tveita knows that
gpvos 3y ago
This is "printing instead of doing an action". That is not the same as debugging. Also, lightweight printf debugging is often more appropriate than using an unwieldy debugger.
- tveita 3y ago
  > Also, lightweight printf debugging is often more appropriate than using an unwieldy debugger. Then use a good one! :) This is tongue in cheek, of course, but think about steps 2 and 3; this is where you want to verify that you understand when the method is called and what it gets as input. The method might receive six nested structs as arguments, how many tries does it take you to print all the relevant information? Does what you're trying to print have a useful string representation? Set a breakpoint in your Invoke method. Inspect the arguments as deeply as you need to. Check the stack to see where the method is actually being called from. Verify that you can access any other objects you need and that they are in a sensible state. One good breakpoint can save you dozens of edit-compile-run cycles. printf debugging shines when you need to investigate a property over many individual calls - What array sizes is this function being called with? At what point does this optimized calculation diverge from the reference implementation? Are functions A and C ever called in succession without B being called in between?
  - gpvos 3y ago
    Fair enough, there's something to say for both sides. When using an IDE, I do often launch into the debugger immediately. Then again, using printf means you start out with a service that already logs all requests; you can commit that code, which you generally can't do with debugger breakpoints. I'm sure there are more arguments either side.

by tveita 3y ago

This Raymond Chen guy should probably look into what debuggers are available on his platform of choice, he could save time by avoiding all this printf() style debugging.

l33t233372 3y ago

Printf style debugging is very nice. I like it more than actually using the debugger in a lot of cases.

yowlingcat 3y ago

Why is printf() style debugging supposed to be a bad thing if done properly? Are you of the opinion that one is supposed to use either/or of these approaches rather than using each approach for different situations to supplement each other?

kragen 3y ago

for context, raymond wrote significant parts of windows going back to the 80s, and tveita knows that

gpvos 3y ago

This is "printing instead of doing an action". That is not the same as debugging. Also, lightweight printf debugging is often more appropriate than using an unwieldy debugger.

tveita 3y ago
> Also, lightweight printf debugging is often more appropriate than using an unwieldy debugger. Then use a good one! :) This is tongue in cheek, of course, but think about steps 2 and 3; this is where you want to verify that you understand when the method is called and what it gets as input. The method might receive six nested structs as arguments, how many tries does it take you to print all the relevant information? Does what you're trying to print have a useful string representation? Set a breakpoint in your Invoke method. Inspect the arguments as deeply as you need to. Check the stack to see where the method is actually being called from. Verify that you can access any other objects you need and that they are in a sensible state. One good breakpoint can save you dozens of edit-compile-run cycles. printf debugging shines when you need to investigate a property over many individual calls - What array sizes is this function being called with? At what point does this optimized calculation diverge from the reference implementation? Are functions A and C ever called in succession without B being called in between?
- gpvos 3y ago
  Fair enough, there's something to say for both sides. When using an IDE, I do often launch into the debugger immediately. Then again, using printf means you start out with a service that already logs all requests; you can commit that code, which you generally can't do with debugger breakpoints. I'm sure there are more arguments either side.