This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Move GDB to C++ ?
> 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.