public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
* C++ draft
@ 2011-06-27 21:08 Tom Tromey
  2011-06-27 21:23 ` [Archer] " Joel Brobecker
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Tom Tromey @ 2011-06-27 21:08 UTC (permalink / raw)
  To: Project Archer

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2011-09-26 21:01 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-27 21:08 C++ draft Tom Tromey
2011-06-27 21:23 ` [Archer] " Joel Brobecker
2011-06-29 19:55   ` Tom Tromey
2011-06-29 21:47     ` [Archer] " Joel Brobecker
2011-06-28  4:33 ` Matt Rice
2011-06-28  8:21 ` Yao Qi
2011-06-28 12:21   ` Gary Benson
2011-06-28 17:08     ` Matt Rice
2011-06-28 17:36     ` Jan Kratochvil
2011-06-29 20:08     ` Tom Tromey
2011-06-29 20:06   ` Tom Tromey
2011-06-30  6:06     ` Yao Qi
2011-09-26 21:01       ` Jim Blandy
2011-06-29 18:52 ` Stan Shebs
2011-06-29 19:03   ` [Archer] " Joel Brobecker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).