This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Move GDB to C++ ?
- From: Tom Tromey <tromey at redhat dot com>
- To: Stan Shebs <stanshebs at earthlink dot net>
- Cc: gdb at sourceware dot org
- Date: Thu, 10 Jul 2008 16:41:13 -0600
- Subject: Re: Move GDB to C++ ?
- References: <487658F7.1090508@earthlink.net>
- Reply-to: tromey at redhat dot com
>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:
Stan> As many know, there is a project afoot to investigate the
Stan> recoding of GCC from C into C++.
I'll send a separate note about this soon, probably tomorrow.
Thanks for raising this topic -- very brave!
Stan> For my part, I think we should do it. GDB has quite a bit of
Stan> object-like structure internally
I think GDB is nearly written in a dialect of C++ already:
* It uses exceptions all over the place.
Instead of throw, gdb uses error().
Instead of try{} catch{}, gdb uses TRY_CATCH.
* RAII is omnipresent, in the form of cleanups.
* Classes exist. For instance, struct cmd_list_element is a class
with a constructor, various fields, accessor methods, and some
virtual methods.
* Subclasses are in use too. The 'struct expression' and 'struct
type' classes essentially have subclasses, they are just written as
discriminated unions or whatnot.
* Templates are used in at least one place -- vec.h.
* I think function overloading is in use too, and default arguments.
One example is parse_exp_1 and parse_exp_in_context.
In all these cases, the C++ code is, in my opinion, simpler to read
and write than the corresponding gdb code. It is also more regular;
whereas in gdb some "virtual methods" take a 'this' pointer, some do
not; some classes have destructors, some do not (these are both things
I ran into on the Python branch). Finally, C++ provides better
support for abstraction, specifically via access control.
So, I am in favor of this change.
Tom