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::bimapis 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::bindmake 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