This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Move GDB to C++ ?
On Wednesday 30 July 2008 21:42:17 Mark Kettenis wrote:
> > 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.
And they make it easy to choose the right container for the task, e.g.
the one with the needed performance characteristics. In C, one
basically starts of with a linked list, and only if it really, really hurts
to a degree that one can't ignore the problem
> But they don't really help when you need to debug your
> code since they are implemented using templates.
It's somewhat funny to hear that kind of argument from someone
who is writing debuggers. Isn't it your self-assigned task to make
debugging easy? If it isn't easy (and I do agree that debugging
common C++ with plain gdb is a pain), it is - sorry to be blunt -
at least partially your fault.
Instantiated class templates are not different from ordinary structs, and
there is no real problem in presenting the "children" of a, say,
std::list<int> as if they were ordinary struct members, at least for a
given (say, current gcc's) implementation.
> The result is incomprehensible compiler errors when you make
> a mistake in your code.
Well, at the time I started coding (and probably yours, too ;-)),
compiler were considered "user friendly" when they did not just
abort on faulty input but were so nice and gave the number of
the problematic line, too. (a) one gets used to it, and (b) it's
far more convienient nowadays. Especially gcc is pretty good
at pointing out possible reasons _why_ compilation failed.
> 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.
See above. That's the problem of the frontend you use. Of course,
one reason that most frontends do not display container contents
nicely is that gdb is not easy to interact with programmatically, and
behaviour details change by the release, so frontend writers are
likely to skip that part and just present you the C view of the world.
> 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.
And a hash map might be the proper choice for a container
performance-wise, and you are lost with "openly coded plain C".
> > 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.
Gdb performance is an issue. I have projects were starting
up gdb easily takes 20 seconds or more. The same code
shows up in the debugger from the Dark Side in a snap.
> My experience is the exact opposite. Behind that simple assignment
> might hide a very costly operation.
First off all, not all such operations are on the critical paths in the
application, so there usually lots of places where an expensive 'a = b;'
might waste a few hundred CPU cycles over the optimal, 20 line, highly
optimized "manual copy"; but the latter wastes the developer's time, the
reviewer's time and the code reader's time, and human time is usually
regarded more valuable than CPU time.
In the other cases, the profiler will tell you, and it's up to you to decide
whether it's worth that price in that situation and whether you need
hand-craft this particular piece of code. Or simply optimize the container
you use _without_ touching the "user code". That's a liberty you do not
have with "openly coded" structures.
> > 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?
Yes.
Andre'