This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: suggestion for dictionary representation
On Fri, Sep 27, 2002 at 01:07:57PM -0500, Jim Blandy wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
>
> > On Tue, Sep 24, 2002 at 10:46:02PM -0500, Jim Blandy wrote:
> > >
> > > Daniel Berlin <dberlin@dberlin.org> writes:
> > >
> > > > On Tue, 24 Sep 2002, Jim Blandy wrote:
> > > >
> > > > >
> > > > > > Also, for what it's worth, I'm still not ready to completely give up
> > > > > > on representing members of classes via a dictionary; that would
> > > > > > provide another place where a linear dictionary environment could be
> > > > > > useful.
> > > > >
> > > > > I agree, but it's worth noting that `struct symbol' is 52 bytes long
> > > > > on a Pentium, whereas `struct field' and `struct fn_field' are 16
> > > > > bytes long.
> > > > >
> > > > > Not that that necessarily matters. We know GDB does have memory
> > > > > consumption problems, but I have never seen those problems really
> > > > > analyzed.
> > > >
> > > > Um, I have these statistics, but I need to know *exactly* what you want to
> > > > know to be able to give them to you.
> > >
> > > On large C++ programs, how much of a difference would it make if we
> > > used `struct symbol' objects (52 bytes long) to represent data members
> > > and member functions, instead of `struct field' and `struct fn_field'
> > > objects (both 16 bytes long)?
> >
> > I'm not sure this is the way to go - we could have a dictionary of
> > something other than struct symbol, probably.
>
> Well, for fields, I think you're right. The field list is
> intrinsically an ordered thing; a dictionary is not.
>
> But not for methods, either? Wouldn't it simplify overload set
> computation to have methods and ordinary functions represented using
> the same structure?
Not really. First of all, you never have to deal with both at the same
time:
void foo(int x)
{
printf ("Int ver\n");
}
class bar {
public:
void foo (double x) { printf ("Double member ver\n"); }
bar() { foo (1); foo(2.); }
};
int main()
{
bar baz;
return 0;
}
Both calls will get the member version.
Secondly, getting the type would probably be all of two lines of
special case; for the memory savings that sounds pretty good to me.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer