I used to be a Visual Studio Debugger Wizard (BTW, it's an excellent debugger)... now I don't remember the last time I used a conditional breakpoint.
Working on a codebase designed, from the start, for testability, changed everything. So I totally agree with your last sentence about TDD ; although it took me nearly one year of practice before I could write solid unit tests (which wouldn't break every now and then because of some interface change), and that I still find it hard to write them before the code being tested (however, I do find it harder (impossible?) to write a unit test for code written more than one month ago).
I still use cgdb from time to time, to quickly print a backtrace or the origin of an exception/segfault.
By the way, I have the feeling that language constructs like lazy arguments, RAII, scope(exit), concurrency, and exceptions, make following the flow of control less and less relevant. In the long term, some amount of emancipation from one's debugging tools might be strategic.
I used to be a Visual Studio Debugger Wizard (BTW, it's an excellent debugger)... now I don't remember the last time I used a conditional breakpoint.
Working on a codebase designed, from the start, for testability, changed everything. So I totally agree with your last sentence about TDD ; although it took me nearly one year of practice before I could write solid unit tests (which wouldn't break every now and then because of some interface change), and that I still find it hard to write them before the code being tested (however, I do find it harder (impossible?) to write a unit test for code written more than one month ago).
I still use cgdb from time to time, to quickly print a backtrace or the origin of an exception/segfault.
By the way, I have the feeling that language constructs like lazy arguments, RAII, scope(exit), concurrency, and exceptions, make following the flow of control less and less relevant. In the long term, some amount of emancipation from one's debugging tools might be strategic.