Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
> Indeed, gdbserver would need to remain pure C,
[...]
> This is important, because we want gdbserver to be usable
> in #1, resource constrained scenarios where the C++ dependency would
> be unacceptable.  We don't want there to need to be other gdbserver-like
> programs specialized for such environments, and gdbserver to be usable only
> on bigger machines.  We want gdbserver to run everywhere.  And #2, the debugger
> is one of the first programs that is desirable to get running on a new
> system/board.  Usually you get C going much sooner than C++.

While it was said before gdbserver should stay in C I did not see it long-term
maintainable - due to the code sharing goals.  While I wanted to simplify the
talk excluding gdbserver first we can talk even about C++ization of gdbserver.

Which specific platforms do you talk about which is UNIX compatible (=FSF
gdbserver compatible, not just an embedded stub) and cannot run C++ programs?
(*)  Please give examples of viable platforms with future development.

(*) The smallest device I know about is SIM card - and it runs Java (Card) VM,
    therefore more heavy environment than C++.


> The event-loop.c file is yet another thing.
> It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c.
> There goes another use for C++ classes.

The mail lists all the code parts which cannot be C++ized.  I do not find that
too interesting.  I find interesting code parts which can be C++ized - such as
anything about symbols/types outside of gdbserver.


> (On a sidenote: I get the impression from some that C++ would be mostly
> useful for the stronger static typing,

Not just that one, std::string vs. cleanups vs. exceptions are even more
wanted (by me); just static typing (probably) cannot be done without C++,
the other parts are still being fixed up without C++.


Thanks,
Jan