This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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

Re: [RFA] Integrated hashtables take 2



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


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