After working on gdb for a while, I’ve noticed a funny flaw: gdb is too good at debugging itself.
I often hear stories of disappointment from gdb users. It doesn’t scale well. It doesn’t handle threads well. It only has a vague understanding of the C++ that users insist on typing at it. That was my experience, too, when I was working on C++ (or worse: Java) programs.
But gdb itself doesn’t use any of these features. It is written in more or less plain C. It is single-threaded. It is not too big. It does not rely on many shared libraries. So, as a gdb developer, I find it is pretty easy to forget that it has flaws.
I once heard about a C++ compiler written in C++ where, in order to counteract this same sort of problem, its developers mandated that the compiler use every existing C++ feature.
For fun try to picture code review on that project. “Bob, this patch looks ok, but I think you should use operator overloading and exceptions here.”
That said, I think the “share the pain” theory is one reason — among several — to change gdb’s core to be implemented in C++.
Another way to combat complacency would be to debug other programs while working on gdb. I find this pretty hard to do, though. I tend to allocate more and more of my time to hacking my main project at the expense of the secondary one.