Re: Move GDB to C++ ?

[Andrew Cagney <cagney at gnu dot org>]

Vladimir Prus wrote:
> Andrew Cagney wrote:
>
>   
> > Instead of changing GDB to C++ and hoping the change will magically
> > transform GDB's code base into a clean ideal design; should we instead
> > be focused on trying to address what I suspect is the underlying
> > motivation here - a desire to clean up and re-structure GDB's code base
> > so that it more clearly corresponds to a more modern Object Oriented design?
> >     
>
> I think that trying to use better design without support of a language for which
> such design is a native one, would be considerably harder. GNOME is a perfect 
> example -- in attempt to use OOP in C, they have this GObject thing which is an
> approximation of real classes, only harder to use. Ah, and there's even separate
> tool, called GOP, that takes class definition in some meta-language and produces
> .h and .c file. So, there's fairly complicate non-standard solution for
> an already-solved problem.
>   

The question I'm asking here is are we focusing on C++ as a solution, 
and mistakenly trying to rely on its features as a solution, when we 
should instead be first focusing on the design, what ever the 
implementation language?

> Let's use one example in GDB -- values. Presently, struct value has a 
> field lval_type, and in a number of places, a switch over lval_type is
> made. This switch-over-type is a typical red-flag in OOP programs; in case
> of GDB this makes it hard to understand what is exact behaviour of 
> lval_register, for example. CodeSourcery's implementation of register browing
> required extending struct value, so that fetching a value goes via special
> remote protocol packet. This ended up been not exactly nice. If struct value
> was a base class with a defined interface, and each kind of value (rvalue, lvalue,
> register, etc) were a derived class, then the internal logic of GDB would be
> more clear, and adding new kinds of values would be much simpler.
>   

For instance, an alternative value relationship we've seen proposed:

    value
        has-a type
        has-a location

    location
        has-a 1:N piece

   piece
       is-a memory piece
       is-a register piece
       is-a constant piece

(credit to tthomas for this refined design) which removes gdb's 
limitation of a value having a single [register] location.  This is a 
design alternative, not an implementation alternative.  Once we've 
concurred on the design we can implement it using language-of-the-day.

If, in attempting to make these changes we find that the C 
implementation truly cumbersome then we've a compelling story for 
language change.    This is assuming that the intent here is find ways 
to allow greater architectural reform in GDB (and a language change is 
just an aid to that goal).  You seem to at least be agreeing with this?

> I'd be happy to actually refactor struct value in this way, but only when using
> the proper tool, namely C++. I don't want to complicate things by emulating
> classes in C.
>
> Actually, it appears that this C++ discussion got a bit stalled, apparently since
> nobody wants to make the first step. So, how about his plan of action:
>
> 1. GDB is made compiled with C++ compiler, with resulting errors removed.
> 2. I refactor struct value, and folks get to comment if the resulting code
> is better, or worse, than what we have.
>
> Comments?
>
> -  Volodya
>
>
>
>
>