Will therefore GDB utilize C++ or not?

[Stan Shebs]

On 4/4/12 1:47 PM, Tom Tromey wrote:
>
> At the GCC Summit, I once again brought up the perennial idea of
> moving GDB to be implemented in C++.  There, we agreed that as a
> follow-on to that discussion that I would raise the topic among the
> GDB maintainers, and in particular present my migration plan.

I support this plan.

Many of the existing poor-cousin bits of infrastructure date back to a 
time when C++ was not a viable candidate for a widely-available tool, 
and others, more recent, are conscious imitations of C++ capabilities.  
At this point it starts to look a little perverse that we are doing a 
half-million-line program in C.

The changes will be low-impact, perhaps even less visible than the 
K&R/ANSI C compatibility hacks that we maintained for so long.

A secondary benefit will be that it opens up the use of minor C++ 
features, without getting us into the C90-vs-99 dilemma that has kept us 
from taking advantage of those.

>
> I don't believe we should convert all of GDB to C++.  In particular I
> think gdbserver should remain as pure C, and likewise any code shared
> between gdbserver and gdb should be kept as such.

I don't know that it matters that much for GDBserver anymore.  When 
giant C++ apps like Firefox are running on handheld devices, it's a 
little hard to see that a handful of C++ library functions and and EH 
data section in GDBserver are going to make it or break it on targets 
that people are developing for today.  Plus I note that GDBserver is 
picking up a load of functionality, and the truly space-conscious are 
better-advised to build a custom stub that is stripped down to just the 
bits they're going to use.


Stan