This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Move GDB to C++ ?


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]