This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA] Integrated hashtables take 2
- To: neil at daikokuya dot demon dot co dot uk
- Subject: Re: [RFA] Integrated hashtables take 2
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Sat, 19 May 2001 11:32:21 -0700
- Cc: gcc-patches at gcc dot gnu dot org, zackw at Stanford dot EDU
- Organization: CodeSourcery, LLC
- References: <20010519185946.A2106@daikokuya.demon.co.uk>
I'm really glad to see this stuff getting worked on. Getting rid of
these inefficiencies is very good.
I think it's a mistake to do the tree-core.h thing. We should keep
cpplib independent of GCC. I think that's a very important
abstraction barrier. It would be better to have cpplib.h define a
structure, like this:
struct cpp_identifier {
char data[N];
int length; /* Why is this not a size_t anyhow? */
const char *pointer;
};
Make N a constant defined in some configuration file to match the size
of struct tree_common, or play some other similar game.
Then, do a check that tree_identifier and cpp_identifier are layout
compatible at startup in toplev.c, to make sure they are in synch, and
then just cast between them.
Is this astonishingly ugly? Yes. But maintaining that independence
is worth it.
Tying cpplib to gcc too closely is bad. In C, the traditional way to
do that would be to use a `void *' for data -- but that just doesn't
work for us, given both that we are trying to eliminate dynamic memory
and given the way tree.h is set up. What you really want here is C++,
with templates, when this would all Just Work, but you don't have
that.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com