Re: Move GDB to C++ ?

[Eli Zaretskii <eliz@gnu.org>]

> Cc: gdb@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 29 Jul 2008 21:59:08 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> So will someone please tell, loud and clear: what do we want to do the
> Eli> day after GDB is rewritten in C++?  Let's suppose that we magically
> Eli> fast-forward to the day after everything was refactored and GDB is
> Eli> 110% pure, OO, C++ -- what will we do the next day that we cannot or
> Eli> have difficulties doing today?
> 
> Nobody is proposing that we stop all work and rewrite GDB in C++, then
> look to see what we could do with it.

Did I say that someone did propose this?  If you think I did, I
probably failed to express myself clearly.

> Aside from the one-time effort to make gdb compile with a C++
> compiler, it can be introduced gradually.
> 
> 
> C++ is not a silver bullet, it is an improvement.

Yes, but still no answer to the question I proposed.

> I think much of Ian's PDF on moving GCC to C++ applies just as well to
> gdb:
> 
>     http://www.airs.com/ian/cxx-slides.pdf

Those slides have only one _real_ GCC-specific argument in favor of
C++: on slide 11.  All the rest is general comparison between C and
C++ based on toy examples.

What I would like to see, as a minimum, is a dozen such arguments, for
some of the more important parts of GDB code, that show how switching
to C++ will make those parts easier to understand, extend, and
maintain.  For now, I've heard only one such argument: about struct
value, and it wasn't anywhere as detailed as a convincing argument
should be.  If someone would come to me with such arguments on my
daytime job, she would be out of my office in less than 2 minutes.

> Naturally, every construct in C++ can be written using C.  This is
> obvious, because gdb already does it.  However, in C++ it is generally
> less work, and the result is often better -- more regular, simpler to
> reason about, more type-safe, less buggy, or in some cases faster.

As I said, such general arguments don't convince me where I get my
paycheck, and that's a place where I can actually force people to code
according to some standards.