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

[Tom Tromey <tromey@redhat.com>]

I'm sorry this reply has taken so long.  I didn't mean to let this drop
off -- I think a sort of generic problem in gdb is over-use of the
pocket veto -- but I've been away, sick, etc.

John> I wish you'd retract the terms you used for my ideas (bogus, straw
John> men, weird, etc).

Ok, I retract those adjectives.

John> All of my messages on this topic have been serious.

Ok.

John> Re (1), I could say that C is already quite close to C++, since GDB
John> is written in C and you say GDB is already quite close to C++.

Your statement here is a generic one, disconnected from any particular
fact about GDB -- a problem that pervades your response.  It could apply
to any C program.  But, my argument is about GDB in particular; and
cannot be transferred to any C program as-is.

You can see this most easily if you re-read the bullet list in
http://sourceware.org/ml/gdb/2012-04/msg00044.html

John> Large modular programs use modularity techniques.  Some of those
John> are also used by C++.  Again, nice observation, but what does it
John> have to do with converting GDB to C++?

The list isn't only about modularity techniques.  For instance, few pure
C programs use exceptions -- it is a rarity.  But, GDB uses them
ubiquitously, and we know that their current expression in GDB causes
bugs; bugs which are easily avoided in C++.

John>   *  Just because it's written in C++ doesn't make it
John>   maintainable.

Nobody claims this.

John> See, GDB was a large, complex program even in 1991.  And the average
John> guy who makes a patch to a large program, makes it solve his
John> particular problem but usually breaks six other things in the process.

There are lots of kinds of patches.  And, there is no silver bullet.  I
don't think C++ will magically solve everything, but it will remove some
subset of bugs and make some planned changes easier.

And, this proposal can't really be disconnected from gdb as it currently
is.

For example, look at the Python layer.  Despite patch review and our
knowledge of the issues, we still have error-checking and
reference-counting bugs in the code.  You can go through the list
archives and find them.

This is an example of the sort of problem that we could define out of
existence.

Cleanups are another good example.  I've personally fixed any number of
small memory leaks, cleanup misuses, etc -- but more remain.  RAII is
simply a better programming technique.

The frame cache is yet another example.  There's a bunch of bugs
relating to keeping frame_info objects across invalidations of the frame
cache.  These are very tricky to see via patch review.  This is also a
hard problem to fix systematically in C.  In C++ you can do it pretty
easily though.

John> So if there are tons of contributed patches in gdb-patches, for
John> "purely avoidable problems" that are in the shipping version of GDB,
John> then they probably result from prior acts of the GDB maintainers, who
John> inappropriately applied patches from people who don't understand the
John> structure of GDB.

Patch review will never be perfect.  It is typical for even very
experienced gdb hackers to miss things during review.  My view is that
we should use multiple tools to eliminate bugs at their source -- and
that the cheapest way, by far, is to define them away by letting the
compiler do the heavy work.

Tom> There are some threads on gdb-patches recently about lazy CU expansion

John> Also, I'm not sure what "lazy CU expansion" is.

See http://sourceware.org/ml/gdb-patches/2012-04/msg00154.html

Basically it is an attempt to scale gdb's symbol reading performance.
Even this may not be sufficient, given the size of programs we're seeing
now.

I'll reply to the rest of this in a separate note.  It is really a
different thread.

Tom