Move GDB to C++ ?

Eli Zaretskii
Wed Jul 30 18:45:00 GMT 2008

> From:  Vladimir Prus <>
> Date:  Wed, 30 Jul 2008 11:18:09 +0400
> > Unless we can answer this question, refactoring and rewriting is
> > simply waste of resources, nothing less, nothing more.
> And here, you also surely know what is generally goal of refactoring --
> to make code simpler and more amendable for future change.

No, refactoring always has some specific goal.  Only given a specific
goal, can one weigh the alternatives -- one to keep existing design
and code and change it, the other to refactor it and then extend the
result.  You need to have a clear goal so that you could balance
advantages against disadvantages.  Without a goal, all you have is
disadvantages (the overhead and effort of refactoring), because
advantages cannot be estimated without a specific goal in sight.  How
do you estimate an advantage of ``making code simpler and more
amenable to change''?  You can't.

> I do think that struct value needs refactoring -- because I know
> that adding new kind of value was a pain in current codebase.

But if we won't add another kind in 10 years, maybe that's not a

And anyway, can you present a convincing case for refactoring struct
value, one that shows the details of adding a new kind each way?

> I do think that target stack needs cleanup, because we ran in some
> inconveniences during non-stop work, and because multi-process work
> will have to change it seriously.

Again, please be specific: show me how doing this in C++ would be much
better than in C.

> Those areas do need to be refactored to be hackable-on, and such refactoring
> better make use of a language suited for OOP -- which those areas try to
> approximate using C, now.

Sorry, this is circular reasoning.  I'm hacking GDB since 1999
(although not as much as I would like to), and I never had any special
need for OOP.  Not even when I introduced cross-platform code such as
x86 watchpoint support.  It will take more than just general
hand-waving to convince me.

More information about the Gdb mailing list