Re: Will therefore GDB utilize C++ or not?

[Tom Tromey <tromey@redhat.com>]

>>>>> "John" == John Gilmore <gnu@toad.com> writes:

I didn't reply to some of your earlier notes since they were just
clearly bogus -- straw men, weird characterizations and generalizations
bordering on the insulting, etc -- but a couple people asked me
privately about these.  So I guess I'll respond to this one after all.

John> If you are arguing that our test suite does not exercise gdb well
John> enough to detect simple coding bugs, that argues for spending more
John> time on the test suite, not rewriting working code into C++.

It doesn't really work this way.  Test suites and reviews are good tools
but of course they are imperfect.  You can grind away to the point of
diminishing returns, but the point is not perfection but rather to
accelerate development at a reasonable cost, not an unreasonable one.

The thrust of the argument that I posted, which you have basically
ignored in all its particulars, is (1) gdb is already quite close to C++
in practice, albeit a badly broken dialect, and (2) the constructs gdb
implements are in fact difficult to use correctly in practice.  The
evidence for #2 is all in the gdb-patches archives, mostly along the
lines of bug fixes for various purely avoidable problems.

In programming there are usually two sets of problems to solve.  First,
there are the domain problems.  Then, there are the problems of
expression; these are largely self-induced problems which tend to get
worse as your program ages.  My view is that gdb is hampered, though not
crippled, by the latter class.

John> BTW, someone argued that C++ would improve memory allocation for
John> e.g. symtabs.  We used to allocate those in our own region-based memory
John> allocator, so thousands of symbols could be freed at once when new
John> symbol files are loaded.  Do we not do that any more?

We do.

Full symbols are already reasonably C++y, what with the ops vector.

There are some threads on gdb-patches recently about lazy CU expansion
where, reading between the lines (as one must usually do on gdb-patches,
since bringing up C++ just makes for a distracting argument), you can
see how C++ would help.  Namely, we'd like to change symbol so that it
can optionally point to the corresponding psymbol, but that means
wackiness in the accessors; a problem easily and cleanly solved by
subclassing and virtual methods.  Note that we already have one subclass
of symbols, and there's some indication we'll need more regardless.
Anyway, this is a case where there would be a clarity benefit without
any loss of space (in fact it would be in service of space and
performance gains).

Partial symbols are a different matter.  I think they are a bad
candidate for any sort of change, on the grounds that they are both
reasonably isolated and also extremely space critical.

Tom