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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> Even Android/Bionic doesn't support C++ exceptions (not sure
Pedro> if it doesn't in recent versions or not).

I think this is an interesting point, but downthread Paul Smith raised
the idea of statically linking libstdc++; and I was wondering whether on
really space-constrained systems one might enable SJLJ exceptions to try
to save space from the unwind tables, my thinking being that this would
reasonably faithfully mimic how the code actually works today.

Pedro> It is very much not clear to me that it is worth the pain (that I
Pedro> tried to show we will end up with) to bring in C++ for this.
Pedro> Symbol/types even are long lived objects, it's not common at all
Pedro> to need to worry about leaks (RAII/exceptions) here.  And all we
Pedro> have are simple hierarchies.  As much as I like C++, C does quite
Pedro> fine here too.  The language it is written in is not the problem
Pedro> with our symbol tables.

We're going to make symbols more complicated to make lazy CU expansion
work, and maybe some other things.

The issue isn't whether it is possible, but instead the cost.  On the
whole I think we spend a lot of time in gdb tending to self-created
problems.  Open data structures (symbol tables are particularly bad
here), inconsistent use of accessors, etc, make some kinds of
refactorings harder than they need to be.

I realize that switching to C++ is not a panacea for this.  Fixing
symbol tables is just hard regardless of how we do it, because the
original sins are all baked into the code already.

But, there are changes that this move would undoubtedly facilitate.
For example, I think we need to virtualize struct value storage to deal
with VLA and sliced arrays.  To me this looks pretty awful from C; but
simpler from C++.

Pedro> Even RAII is not _that_ different from cleanups.

No, it really is.  It is not dynamic, and you don't have to remember to
call do_cleanups on all exit paths.

I've fixed any number of memory (and, IIRC, file descriptor) leaks
caused precisely because cleanups are less good than RAII.

Basically, with cleanups the default is full generality, but this is
wrong.  With RAII the default is block scoping, and you have to expend
effort to do weird stuff.

Pedro> We still need to have a way to tell the RAII wrapper objects to
Pedro> stop managing whatever they're managing, for instance.

There are plenty of canned solutions.

Pedro> We should consider this very very carefully, not just flip just
Pedro> because.

I don't think that is an accurate characterization of the proposal.
I realize the threads get a bit heated though.

I agree that we should consider it very carefully.  And I think we are.

Tom