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

[Pedro Alves <palves at redhat dot com>]

On 04/09/2012 08:05 PM, Jan Kratochvil wrote:

> 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.  


I do.

> 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.


GNU's not UNIX.  Haven't you heard?  And why do you keep excluding embedded
things?  This is a recurrent point you raise in several discussions.
Haven't you noticed the trend towards mobile computing?  Even Red Hat
has business in the embedded world since a long long time (GNUPro and
services).  Even Android/Bionic doesn't support C++ exceptions (not sure
if it doesn't in recent versions or not).

I don't even need to leave my office to find such a system.

$ssh 192.168.0.253
[pedro@NAS][~]
>ls /usr/lib/libstd*
ls: cannot access /usr/lib/libstdc*: No such file or directory
> uname -a
Linux NAS 2.6.24.4 #1 Tue Feb 10 11:00:22 GMT 2009 armv5tejl unknown

>> 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.  


It explained that many core parts of GDB should stay in C.  Which served
to raise awareness that converting just a few parts to avoid a few bugs and making
things neater here and there has a lot of potential for making things worse.
I find interesting code parts which can be C++ized - such as

> anything about symbols/types outside of gdbserver.


It is very much not clear to me that it is worth the pain (that I tried to show
we will end up with) to bring in C++ for this.  Symbol/types even are long lived
objects, it's not common at all to need to worry about leaks (RAII/exceptions)
here.  And all we have are simple hierarchies.  As much as I like C++, C does
quite fine here too.  The language it is written in is not the problem with
our symbol tables.

>

> 
>> (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++.


Sure, there will always be bugs.  C++ doesn't magically make all bugs go away.
Even RAII is not _that_ different from cleanups.  We still need to have a
way to tell the RAII wrapper objects to stop managing whatever they're managing,
for instance.  And with C++98/03, we have to write these things out of line, like
cleanups too.  What I'm saying is that our C mechanisms work.  There is no need to
rush to replace them.  We should consider this very very carefully, not just
flip just because.

-- 
Pedro Alves