Re: Move GDB to C++ ?

[Andrew Cagney <cagney@gnu.org>]

Andrew STUBBS wrote:
> Tom Tromey wrote:
>> I think GDB is nearly written in a dialect of C++ already:
>
> ...
>
>> In all these cases, the C++ code is, in my opinion, simpler to read
>> and write than the corresponding gdb code.  It is also more regular;
>> whereas in gdb some "virtual methods" take a 'this' pointer, some do
>> not; some classes have destructors, some do not (these are both things
>> I ran into on the Python branch).  Finally, C++ provides better
>> support for abstraction, specifically via access control.
>
> I tend to agree with this statement. In particular I would say that 
> destructors would be much easier to follow than cleanups.
>
> I'm not going to make any judgement about whether there's a business 
> case for doing the work, but here's a question:
>
> A while ago there was some idea of a libgdb that would abstract the 
> debugger back end from the interface (or I may have totally 
> misunderstood what the whole thing was about). I haven't heard much 
> about it recently, and the libgdb that exists seems to be something of 
> a build artefact, rather than a useful abstraction.

I think of it as a good high level concept, but yes, as Daniel points 
out, the libgdb implementation and approach are long dead.  For 
instance, if gdb were more clearly broken into a number of components, 
we'd be able to implement tools such as gstack and gcore directly (as 
they were intended) and not as wrappers or hacks around the gdb cli.  An 
initial step might be to clarify these internal interfaces, any thoughts 
on that?

> If such an idea still exists, what affect would switching to C++ have 
> on that plan? Would it make it easier? Or would it just make it 
> incompatible with non-C++ projects?
>
I think it would help.  For instance, Eclipse has started pushing a more 
abstract debugger interface - DSF - it expects the target to implement a 
very abstract O-O model of the target system.  Being able to implement 
such an O-O models directly in an O-O language would greatly simplify 
things.

Such an abstraction may even prove useful to the Python bindings, I'd 
imagine the combination of that and PyGtk to be a very empowering.

-