Re: Move GDB to C++ ?

[Stan Shebs <stanshebs@earthlink.net>]

Andrew Cagney wrote:
> The one question I would pose though, is bashing up the current GDB 
> code base until it compiles with C++ a reasonable approach?  Each time 
> C++ has been suggested previously, that has been the proposed path 
> forward, and each time it has not moved (I've even tried it my self).  
> Perhaps, instead, we should approach this more on a component basis - 
> stack, expr, type, proc, debug-info, ..., and convert each chunk in 
> turn.  And also make use of newer technology such as some of the 
> technology that accompanied GOLD.  This would suggest working in 
> parallel, in a src/gdbxx (gdb++) directory; while this is of course 
> longer and harder, I believe we'll see better results.
It's certainly an approach worth thinking about. Presumably the point of 
working in a different directory is that the code might be expected to 
be broken or nonportable for a period of time, but when that happens you 
can run afoul of limited commitment levels, with people only able to 
work on gdbxx when they don't have regular gdb tasks. If everyone is 
forced into the same straitj^Wsource tree, dealing with mid-transition 
brokenness is (usually :-) ) justifiable as part of the job.

An intermediate strategy might be to enable C++ in the trunk, then do 
component replacement on branches. GCC has been having some success with 
this; if a branch has something like rewritten symbol handling, then 
regular merges will go pretty quickly, and people that don't want to 
deal with symbol stuff can continue to work on trunk, knowing that the 
branch code will come in when it's ready.

Stan