Re: Will therefore GDB utilize C++? Not.

[Michael Eager <eager@eagerm.com>]

On 04/06/2012 06:16 AM, Joel Brobecker wrote:
>>> I do not recommend that GDB use C++.
>>
>> I agree 100% on all points. I came to the same conclusions 10 years
>> ago. Everything i do now is C, and i only poke with C++ to grab
>> something out of it or to reverse engineer.
>
> I wish we would stop discussing about the language itself, and argue
> the technical points that the pro-C++ camp were bringing up. There are
> a number of issues with GDB's design there were raised, and solutions
> involving the use of C++ were proposed. As far as I know, the anti-C++
> camp has rejected C++ in general based on general and vague arguments,
> rather than argue the specific points that have been brought up. We are
> NOT talking about using ALL of C++, we are talking about using
> a reasonable subset that would allow us to expand a bit what the language
> can do for us.

I'll echo Joel -- complaints about C++ language design don't add much to
the discussion.

I've long been an advocate of C With Classes.  I'm less in favor of
using other features in C++, perhaps not so much from the technical concerns,
which I do have, but because gcc provides horrible C++ error messages and gdb
provides horrible C++ debugging.  It's been suggested that if gcc/gdb converted
to C++ that both would improve as the developers ate their own dog food.

> And yet, that's exactly what we are doing:
>    - unit elaboration;
>    - gdbarch/language dispatching
>    - exception handling
>    - use of unions to emulate polymorphism;
>    - etc, etc, etc.

Writing several different versions of object-oriented C to implement
these features doesn't make gdb easier to debug or extend.

> So again, the proposal that was put on the table a long time ago
> was that some specific features of C++ be used in order to simplify
> certain areas of GDB's code. The pro-C++ camps has, in my opinion,
> successfully shown how C++ was going to help. The specific arguments,
> in my opinion, should be brought up again, and those specific arguments
> should be discussed, rather than just discussing generalities about
> how horrible C++ is.
>
>> All it requires is a few more short lines of explanatory design
>> notes scattered through the code and clarity of thought.

In many places, gdb comments and descriptions range from meaningless to
useless.  The internals document is far out of date.  In many areas, it
is difficult to understand why the code does the odd things it does.
I'm not sure where "clarity of thought" would be applied.

Working in gdb is not easy.  It doesn't seem to be getting better.
There are many changes which, IMO, would reverse this trend.  One would
be to rewrite the parts which are currently written in object oriented
code with incomplete encapsulation with clear C++ classes and member
functions.  Several parts of gdb are overly complex and would benefit
from refactoring and redesign.  As parts are converted to C++, perhaps
this would give the opportunity for a long overdue review of the design.

There's been an argument that poorly written C++ code is the only
possible outcome of converting gdb to C++.  I don't think that this is
the inevitable result.  Developers can write good C or good C++, as
well as poor C or poor C++.  Especially with gdb maintainers' concerns
for the quality of C++ code, I would expect that converting gdb to C++
would favor (if not demand) producing good C++ rather than just checking
in anything submitted.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077