This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Move GDB to C++ ?
> Date: Wed, 30 Jul 2008 11:45:15 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
>
> Eli Zaretskii wrote:
> >> Date: Tue, 29 Jul 2008 12:35:02 -0700
> >> From: Stan Shebs <stanshebs@earthlink.net>
> >> CC: gdb@sources.redhat.com
> >>
> >> For instance, at this very moment I'm looking at
> >> ALL_OBJFILES and friends, wondering if the introduction of multiple
> >> execs is going to impact overall performance.
> >>
> >
> > And how would that change with C++?
> >
> >
> C++ collection classes would be very effective here. And sure, the same
> things could be constructed manually in C, but then you're using piles
> of macro trickery a la vec.h and you lose all your typechecking etc, or
You mean the C++ STL container classes? Yes they make it easy to
write code. But they don't really help when you need to debug your
code since they are implemented using templates. The result is
incomprehensible compiler errors when you make a mistake in your code.
And every time I need to look at such a container in GDB I spend
minutes and minutes figuring out how to display its contents.
I'm not a fan of macro trickery a la vec.h either. I think actually
"open coding" your containers is preferable in many cases. Linked
lists and dynamically sizable arrays aren't too difficult to
implement of you only need them for two or three different types.
> if you use function dispatching to iterate, you blow your optimization
> opportunities in code that is known to be time-critical.
Do you have any evidence to back this up? As far as I understand the
main optimization strategy for C++ is heavy use of inlining. This
increases the code footprint of your code which in turn blows away
your instruction cache. That's a heavy price to pay for avoiding a
few branch instructions and some stack access.
My experience is the exact opposite. Behind that simple assignment
might hide a very costly operation.
> Good use of C++
> machinery effectively moves functionality out of the GDB source tree and
> lets the compiler do the work instead.
Pushing compile time through the roof and gobbling up several hundred
of megabytes of memory. Will it still be possible to compile a native
GDB on an underpowered ARM CPU with 64MB of memory?