Question

Debugging with gdb, any c++ code that uses STL/boost is still a nightmare. Anyone who has used gdb with STL knows this. For example, see sample runs of some debugging sessions in code here.

I am trying to reduce the pain by collecting tips. Can you please comment on the tips I have collected below (particularly which ones you have been using and any changes you would recommend on them) – I have listed the tips is decreasing order of technicality.

• Is anyone using ‘Stanford GDB STL utils’ and ‘UCF GDB utils’? Is there some such utils for boost data structures? The utils above do not seem to be usable recursively, for example for printing vector of a boost::shared_ptr in a legible manner within one command.
• Write your .gdbinit file. Include, for example, C++ related beautifiers, listed at the bottom of UCF GDB utils.
• Use checked/debug STL/Boost library, such as STLport.
• Use logging (for example as described here)

Update: GDB has a new C++ branch.

Answer 1

Maybe not the sort of ‘tip’ you were looking for, but I have to say that my experience after a few years of moving from C++ & STL to C++ & boost & STL is that I now spend a lot less time in GDB than I used to. I put this down to a number of things:

• boost smart pointers (particularly ‘shared pointer’, and the pointer containers when performance is needed). I can’t remember the last time I had to write an explicit delete (delete is the ‘goto’ of C++ IMHO). There goes a lot of GDB time tracking down invalid and leaking pointers.
• boost is full of proven code for things you’d probably hack together an inferior version of otherwise. e.g boost::bimap is great for the common pattern of LRU caching logic. There goes another heap of GDB time.
• Adopting unittesting. boost::test‘s AUTO macros mean it’s an absolute doddle to set up test cases (easier than CppUnit). This catches lots of stuff long before it gets built into anything you’d have to attach a debugger to.
• Related to that, tools like boost::bind make it easier to design-for-test. e.g algorithms can be more generic and less tied up with the types they operate on; this makes plugging them into test shims/proxies/mock objects etc easier (that and the fact that exposure to boost’s template-tasticness will encourage you to ‘dare to template’ things you’d never have considered before, yielding similar testing benefits).
• boost::array. ‘C array’ performance, with range checking in debug builds.
• boost is full of great code you can’t help but learn from