C++ draft

[Tom Tromey <tromey at redhat dot com>]

I've been working on another proposal to move gdb to C++.  I'd
appreciate help with it.  Here is what I have so far.

Do you find it reasonably convincing?  If not, why not?  What can be
improved?  Are there other good initial targets for conversion?  Are
there lurking problems of which I am unaware?

thanks,
Tom

-*- text -*-

At the GCC Summit, I once again brought up the perennial idea of
moving GDB to be implemented in C++.  There, we agreed that as a
follow-on to that discussion that I would raise the topic among the
GDB maintainers, and in particular present my migration plan.

My goal for moving to C++ is to make GDB more robust.

My view is that GDB is already written in a poor cousin of C++.
Nearly every feature that people hate about C++ is already in use in
GDB.  This list is not exhaustive, just informational:

* Subclasses.  See general_symbol_info.  struct value and struct type
  would be improved by them.

* Virtual functions.  gdbarch, languages, and values all use these.

* Overloaded functions.  Anywhere you see a _1 suffix.

* Templates.  Both observers and VEC are templates.

* Exceptions.  Used ubiquitously.

* RAII.  Cleanups, but they are dynamic and more error-prone.

In most cases, GDB's implementation of these features is inferior to
that of the C++ compiler.  Its exceptions are slower.  Its data
structures have less type-safety.  Both cleanups and TRY_CATCH are
error-prone in practice.  GDB is needlessly verbose due to using
callback-based container iteration and callback-based exception
handling.

I think a gradual move to C++ would enable us to fix these problems.
I believe it would also provide us a way to fix the ongoing reference
counting bugs in the Python layer.


My proposal is:

1. Modify GDB so it can be compiled with -Wc++-compat.
   This would be the first patch series.  There is already an archer
   branch for this.

2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is
   not complete).  This would be the second patch series.

3. Require C++.

4. Change selected modules to use C++ rather than C.
   I don't think a wholesale change makes sense, but some areas would
   benefit.

   My first target would be to change the exception handling system to
   use C++ exception.  This would enable us to begin using RAII in
   some areas, which would help robustness.

   My concrete plan here is:

   * Use the GCC cleanup-checking plugin I already wrote to detect
     cleanup-aware functions.

   * Modify these functions, using a script, to add an RAII-using
     object to manage the local cleanups.  This is important so that
     we run cleanups at the correct time during stack unwinding.

   * Change throw_exception to use 'throw' and all TRY_EXCEPT
     instances to try...catch.

   * Finally, convert functions to static RAII usage when appropriate;
     this will be an ongoing transition.

   I think our second target will be sorting out Python reference
   counting, so we can avoid the many problems we have had there.