Re: [Archer] C++ draft

[Tom Tromey <tromey@redhat.com>]

Joel>   - Not having access to a good C++ compiler on some of the exotic
Joel>     platforms out there.  Getting a g++ installed by some of us at
Joel>     AdaCore who know GCC will take me a bit of time.
[...]
Joel> I think "FUD" #1 can be dismissed as AdaCore's problem, and we'll
Joel> take care of that. 

I definitely wouldn't put it that way.  If you ship on hosts where this
is a problem, it is best to confront it in advance.

Could you say what hosts you are worried about?

Joel>   - The debugging situation; how well can we debug C++? I'm pretty
Joel>     sure that we've given up on stabs, but we're still doing work
Joel>     on eliminating stabs from platforms such as AIX for instance.
Joel>     It's tough to say how far we are, except that we're hoping that
Joel>     we're getting closer (Tristan is working on and off on that).

Joel> I'd like to be reassured that Fear #2 is unjustified, and that you
Joel> will have reasonable functionality even with GCC 4.5 (that's what
Joel> we use at AdaCore, and we'll probably stay with that for another
Joel> 18months).

Actually, debugging GDB will improve.  Hard to believe, but I think it
is true.

The first thing to remember is that it is a slow transition.  GDB will
start using some C++ features, but it will take a long time -- honestly,
probably forever -- to transition to fully idiomatic C++.

I think GDB can handle C-like C++ perfectly well.  It handles some of
the simpler language additions -- e.g., classes -- quite well.

We have pretty-printing for basically everything in the STL.  This means
that printing collections will actually improve.  E.g., right now,
printing a hash table is difficult because the slots are just void*.
With STL and pretty-printing you will see a more obvious display.

Another improvement is exception handling.  Right now, GDB doesn't work
with longjmp on most Linux distros[*].  But, GCC 4.5 shipped with
_Unwind_DebugHook, so if you have debuginfo for libgcc, then "next" over
a throw in C++ will do the right thing -- take you to where the
exception lands.

[*] We fixed this in Fedora -- but with a local glibc patch and with the
as-yet unmerged SystemTap probe patch for GDB.


There are still a lot of C++ constructs that GDB doesn't handle well.
You can see a reasonably complete list on the roadmap, see the
"Expression Parsing" list:

    http://sourceware.org/gdb/wiki/ProjectArcher

Much of this stuff is not very important, though.  I doubt a program
like GDB would run into most of these.

Tom