On 4/10/12, Jakub Jelinek <ja...@redhat.com> wrote: > That when stepping through code in the debugger you keep > enterring/exiting these one liner inlines, most of them really > should be at least by default considered just as normal statements > (e.g. glibc heavily uses artificial attribute for those, still > gdb doesn't hide those by default).
You do want to step into those inline functions, except when you do. In the short term, we can make the debugger behave as though they did not exist. In the longer term, we really want debugging tools that help C++ programmers. One way to get there is to use C++ ourselves. > > The above is just quickly cooked up examples. A carefully > > designed C++ based API can be self documenting and make the > > client code very readable. It is hard to believe that there is > > no room for improvement in GCC. > > Do you have examples? E.g. I haven't touched gold, because, > while it is a new C++ codebase, looks completely unreadable to > me, similarly libdw C++ stuff. A carefully designed C based API > can be self documenting and make the code very readable as well, > often more so. If you just look at any decently sized code base, it'll look pretty much unreadable. The question is how quickly can someone who learns the base vocabulary can produce reasonable modifications. There are many places where C++ can help substantially. For example: () The C++ postfix member function call syntax means that following a chain of attributes is a linear read of the expression. With C function call syntax, you need to read the expression inside out. () C++ has both overloaded functions and member functions, so you can use the same verb to talk about several different kinds of objects. With C function names, we have to invent a new function name for each type. Such names are longer and burden both the author and the reader of the code. () Standard C++ idioms enable mashing program components with ease. The C++ standard library is based on mixing and matching algorithms and data structures, via the common idiom of iterators. () The overloadable operator new means that memory can be _implicitly_ allocated in the right place. () Constructors and destructors reduce the number of places in the code where you need to do explicit memory management. Without garbage collection, leaks are less frequent. With garbage collection, you have much less active garbage, and can run longer between collection runs. Indeed, a conservative collector would be sufficient. () Constructors and destructors also neatly handle actions that must occur in pairs. The classic example is mutex lock and unlock. Within GCC, timevar operations need to happen in pairs. () Class hierarchies (even without virtual functions) can directly represent type relationships, which means that a debugger dump of a C++ type has little unnecessary information, as opposed to the present union of structs approach with GCC trees. () Class hierarchies also mean that programmers can distinguish in the pointer types that a function needs a decl parameter, without having to say 'all trees' versus 'a very specific tree'. The static type checking avoids run-time bugs. I have written compilers in both C and C++. I much prefer the latter. -- Lawrence Crowl
