This is the mail archive of the
mailing list for the Archer project.
Re: [Archer] C++ draft
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
Actually, debugging GDB will improve. Hard to believe, but I think it
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
[*] 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:
Much of this stuff is not very important, though. I doubt a program
like GDB would run into most of these.