This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |