This is the mail archive of the gdb-patches@sources.redhat.com 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: [patch] some mindless additions of BLOCK_ macros


On Wed, 23 Oct 2002 19:59:06 -0400, Andrew Cagney
<ac131313@redhat.com> said:

> Anyway, ``C++ has all the disadvantages of C, but none of the
> advantages of object oriented programming'' [gordoni].  I'd really
> rather wait for Java - universities are churning out Java
> programmers by the zillions.

I confess, I'm getting more respect for C++ the more I learn about it.
I don't know Java too well yet, though, and certainly having garbage
collection would be nice.  (But not worth rewriting all of GDB to
get.)

> Perhaphs a different marketing approach is needed.  Instead of
> trying to sell the ``splitting of symtab.h into 50 million little
> files'' (which will have everyone running in fear :-), propose the
> creation of a single large block.[hc] that contains an opaque
> block/vector object (which will have everyone thinking - hmm, sounds
> good, can't hurt anyone, certainly do-able, even incremental so no
> need to branch, ... :-).

That's kind of what I'm doing.  Right now, the first plan is to just
try to create a separate block.h, taken straight out of symtab.h:
surely nobody could mind such an innocent action as that?  The
resulting struct block won't be any more opaque than it currently is,
though.  But the main place where it could use some opacity is in its
hashtable, nsyms, and sym members: and there I have a working version
of GDB that handles those using an opaque struct dictionary.

But I need a good excuse to spring that struct dictionary part on
people; right now, it honestly isn't adding anything other than code
cleanliness.  Having it around would have made the transition from
sorted linear blocks to hashtable blocks a lot easier; but that
transition has already happened.  And it's possible that I'll find a
good use for it in the namespace stuff that will require me to
rejigger it slightly; so it's perhaps best to wait until after I've
got a bit more of that under my belt.

David Carlton
carlton@math.stanford.edu


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