Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: gdb-patches@sources.redhat.com, Jim Blandy <jimb@redhat.com>
Subject: Re: [rfc] split up symtab.h
Date: Fri, 18 Oct 2002 14:52:00 -0000	[thread overview]
Message-ID: <ro1n0pb8lfi.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <15792.30892.69140.402056@localhost.redhat.com>

On Fri, 18 Oct 2002 17:10:04 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> I see your point. But I have to agree with Kevin about the tangled
> web we could be weaving. Maybe we could start with a little
> cleanup. Are all the things exported by symtab.h actually used? And
> vice versa, are the files including symtab.h actually needing it? I
> found a few times that some dependencies were left in place after
> some code which needed them had been deleted, etc.

I'll look into that.  Actually, I already have one candidate for
cleanup: if you do "grep 'struct source' *.h *.c", it sure looks like
struct source and struct sourcevector aren't needed.  (And if you add
ChangeLog* to your list of files to grep, it looks even more
suspicious!)  So I think that's the obvious candidate for deletion
from symtab.h.  Also, I think that struct symbol_search could be moved
to symtab.c.  (Though I'd want to look into how that's being used,
because I could imagine that some such structure could be useful for
other files in the future.)  And I'll look into the reverse problem,
as you suggest, namely files that might be unnecessarily including
symtab.h.

Also, another thing that I thought of is that it's silly to propose
breaking it up all at once.  Right now, for example, I'm fiddling with
'struct block' in carlton_dictionary-branch to see how it would be a
good idea to modify it to handle namespace lookup correctly.  (And,
unfortunately, each time I think I understand C++ name lookup rules, I
get surprised by the compiler or the standard, and I realize that my
data structures aren't good enough; it's definitely a good thing that
I'm doing this on a branch...)  So maybe, as an experiment, I'll try
moving 'struct block' and 'struct blockvector' into a file "block.h",
and I'll try to be careful about getting the #includes and Makefile.in
just right; if it turns out to be useful, then I'll consider sending
an RFA to the list.  Getting just that one bit right would be a lot
easier than splitting symtab.h up into 10 files, or whatever I
proposed in my RFC: splitting it up all at once is just asking for
trouble.

David Carlton
carlton@math.stanford.edu


      reply	other threads:[~2002-10-18 21:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-08 13:14 David Carlton
2002-10-08 13:54 ` Kevin Buettner
2002-10-08 15:05   ` David Carlton
2002-10-08 15:11 ` Michael Snyder
2002-10-08 15:22   ` David Carlton
2002-10-18 14:12 ` Elena Zannoni
2002-10-18 14:52   ` David Carlton [this message]

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=ro1n0pb8lfi.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@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