Move GDB to C++ ?

Stan Shebs stan@codesourcery.com
Wed Jul 30 19:19:00 GMT 2008


Eli Zaretskii wrote:
>> From:  Vladimir Prus <vladimir@codesourcery.com>
>> 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.
>   
But to be fair, the coding standards we already impose don't usually 
have quantifiable benefits. In fact your argument could be used against 
any kind of abstraction in the code (how do you prove that the target 
stack is advantageous over some other design?), or against the adding of 
comments (can you demonstrate that any particular comment block is 
helping any other developers?).

I actually think this is one of the unheralded strengths of free 
software over proprietary - we're always able to transform the code into 
something we all *want* to work on. By contrast, proprietary code so 
often degenerates into undocumented spaghetti, because it only gets 
touched when there is an obvious short-term benefit, and only touched 
enough to realize the short-term result.

If everybody simply said "yes, I would prefer working on a GDB written 
in C++", I would consider that sufficient justification all by itself, 
even if there were no technical reasons.

Stan



More information about the Gdb mailing list