This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Move GDB to C++ ?


Eli Zaretskii wrote:
Date: Wed, 30 Jul 2008 11:45:15 -0700
From: Stan Shebs <stanshebs@earthlink.net>
CC: gdb@sources.redhat.com

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.

Can we see some code, please?
How can I do that meaningfully? It depends on how everything else is to be designed. I'm a little surprised that you don't see it yourself, actually.
And sure, the same things could be constructed manually in C, but then you're using piles of macro trickery a la vec.h

Are we still talking about ALL_OBJFILES, or about something more broad? ALL_OBJFILES is just a loop:

#define ALL_OBJFILES(obj) \
for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)
It's the the "and friends" part that is problematic, there are a dozen variants at least, and the potential for doubling that number with multiple execs, because sometimes you still want to iterate through all indiscriminately, other times through only the objfiles for a particular program. There is even a note in objfiles.h about the hazards of the basic "pointer to next" approach, which was the very height of C fashion twenty years ago, but is actually a chronic source of bugs and memory leaks.

Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]