Re: Move GDB to C++ ?

[Vladimir Prus <vladimir at codesourcery dot com>]

Stan Shebs wrote:

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

I think we should use branches only for really terrible changes that
absolutely cannot be done in trunk without making everybody very
unhappy. I think most big changes are also fairly mechanical in nature,
so are not likely to cause serious instability.

- Volodya