This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Move GDB to C++ ?
Eli Zaretskii wrote:
>> From: Vladimir Prus <vladimir@codesourcery.com>
>> Date: Tue, 29 Jul 2008 21:28:05 +0400
>>
>> 1. GDB is made compiled with C++ compiler, with resulting errors removed.
>> 2. I refactor struct value, and folks get to comment if the resulting code
>> is better, or worse, than what we have.
>>
>> Comments?
>
> My only comment is a question: what for? I simply don't see the
> intended purpose or the goal of this.
>
> I happen to manage software projects for a living, and whenever we
> need to upgrade or change some of our tools, it is always because we
> need to do something that is impossible or very inconvenient with the
> existing ones. We never do it out of some abstract wish of "improving
> the design" or "refactoring" for their own sake.
>
> So will someone please tell, loud and clear: what do we want to do the
> day after GDB is rewritten in C++? Let's suppose that we magically
> fast-forward to the day after everything was refactored and GDB is
> 110% pure, OO, C++ -- what will we do the next day that we cannot or
> have difficulties doing today?
As you surely know, most languages are Turing-complete, so you can
do everything in any language, including assembler. The goal,
purely, is to spend less time fighting with the language, and more
time doing useful things.
> 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. This naturally
means that you need either some immediate change to make, or general
idea what will block many future changes. I do think that struct value
needs refactoring -- because I know that adding new kind of value was
a pain in current codebase. 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.
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.
- Volodya