Re: Move GDB to C++ ?

[Stan Shebs <stanshebs at earthlink dot net>]

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