From: David Carlton <carlton@math.stanford.edu>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] some mindless additions of BLOCK_ macros
Date: Wed, 23 Oct 2002 17:20:00 -0000 [thread overview]
Message-ID: <ro1vg3s1ydh.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <3DB737CA.3080308@redhat.com>
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
next prev parent reply other threads:[~2002-10-24 0:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-23 14:17 David Carlton
2002-10-23 16:04 ` Andrew Cagney
2002-10-23 16:19 ` David Carlton
2002-10-23 16:59 ` Andrew Cagney
2002-10-23 17:20 ` David Carlton [this message]
2002-10-23 16:24 ` Daniel Jacobowitz
2002-10-23 16:50 ` David Carlton
2002-10-23 17:18 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1vg3s1ydh.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox