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

[John Gilmore <gnu@toad.com>]

I introduced many of the "tables of C pointers" into GDB.  I could've
opted to switch to C++ at that point.  I did not and am happy that I
did not.  The paradigms we introduced were simple, maintainable,
useful, and documented.  I see nothing wrong with writing in C and
occassionally using a table of pointers (like the dispatch tables in
BFD, or the target selectors) where appropriate.  Just because you
sometimes call through a pointer, or arrange values in data
structures, doesn't mean you need to "move to an object oriented
language".  People who can't do object-oriented programming in a
procedural language perhaps don't understand object-oriented
programming, which is not about syntax, nor about enforcement, but
about deliberately choosing a narrower subset of mechanisms to produce
programs that are easier to maintain.

One of our original reasons for sticking with C is less relevant
today.  GDB is one of the first programs you want to bring up on a new
system, since it can help you debug itself and every other program.
To be useful for that, it needed to be compilable with a very broad
spectrum of relatively simple compilers.  Being written in C++ would
have foiled that.  Nowadays we merely cross-compile and cross-debug,
or emulate the target system from some well-supported host system.
Avoiding the need for a tricky, complicated, and working compiler to
compile GDB is less of a constraint.

I have not yet found an easy-to-maintain large production C++ program;
not in 1991 and not in the intervening 20 years.  I've written a
medium sized C++ program (smqueue).  Based on that experience, I was
never tempted to write a large program in C++.  I have found many C++
programs that are hard to maintain.  Hard to understand, hard to
compile, hard to debug.  As an example, I am currently wrestling with
a commercial success, a production program running at thousands of
sites, that took 12 years of a team of half a dozen programmers to
write and maintain in C++.  It now no longer even compiles, because
the recently graduated programmers who wrote it embedded questionable
C++ constructs deep into its infrastructure, and failed to document
the structures they were building.  I could and will rewrite the
broken parts, but it's very painful to even understand what they were
TRYING to do, because it's undocumented and wrapped up in layer after
layer after layer of templates and inclusion and C++ junk.  They
aren't making objects that have accessors and such; they're using a
"pattern language" that abuses C++ objects to do cheap runtime
type-checking -- or something!  It took hours to just narrow the
program down to a one-page program that would reproduce the compiler
error while being something a human could grasp.  Of course every C++
programmer denies that they are designing or writing a monster like
that.  However, a surprising number end up that way.  It is much
harder to screw up a C program beyond human recognition.  There's not
even a contest for Obfuscated C++, since it's trivial to do without
even intending to!  C++ fails at simplicity and predictability.

The 1990's idea that C++ was the obvious successor to C has clearly
been proven false over the last 25 years.  C is still here and going
strongly.  C++ was an experiment that disproved its thesis -- a
valuable contribution, certainly, but not an example to follow.  Even
the thesis that objected oriented programming is superior to
traditional procedural programming has been disproved (in my mind), or
is at least unresolved at this date.  I would say that over the last
20-40 years the key new insights in programming have been in
portability, simplicity, and pan-global collaboration of focused teams
(version control, automating distributed discussions and bug reports,
distribution, packaging, etc).  The mainstream of system and
application development continues in directions other than C++, such
as C, Java, and Python, not to mention big corners like PHP, C# and
Objective-C.

If you ended up writing parts of GDB in C++ and other parts in C,
anyone who did maintenance on it would have to understand both.  But
C++ is full of ugly traps for the unwary, and things seldom mean what
they appear to a C programmer to mean.  You'd narrow your potential
pool of talented contributors.  And you'd be basing your core debugger
on one of the least well supported parts of C++ -- its
interoperability with traditional C code.

I do not recommend that GDB use C++.

	John