Re: [RFA] Integrated hashtables take 2

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Neil" == Neil Booth <neil@daikokuya.demon.co.uk> writes:

    Neil> Ugh.  But it is, practically, independent - I don't think
    Neil> you can make a realistic argument it's not.  All it has is
    Neil> the bare minimum - the structure and the enum (since we
    Neil> can't predeclare enums), and that's it.

Yes, I understand.  

But basically the thing we're trying to do here is share a hashtable
between cc1 and the cpplib.  Some parts of the hash table are common:
the string, the length, the hash function.  Both clients want to store
some extra data (the TREE_IDENTIFIER stuff in cc1, and any macro
definitions, etc. in cpp).

The CS101 way of doing this would be build a hash table that had a way
of adding arbitrary data.  (Probably a `void*' that clients could
set.)  Then cpplib would define a struct that contained a bunch of
fields about macros -- and another `void*'.  The front-end would
define the contents of the second `void*'.  Or maybe the hashtable
would have a linked list of `void*'s.  But you get the idea.

This approach is good because everything is cleanly separated.
Clients see servers, but not vice versa.  In particular, cpplib
doesn't know anything about cc1.

But, you've now got all kinds of dynamic memory allocation going on,
and resulting inefficiencies.  So, we want to pack the data into the
structures.

In C++, this is simple: you templatize everything, and you're done.
In C, it's not so easy.

How do we pack cc1's information in with cpplibs?  Well, the right
way, since cc1 is the client is to make a derived class of the cpplib
data, and store the additional information there.  Like this:

  struct cc1_data {
    struct cppilb_data cd;
    /* extra stuff here */
  };

Oh, bummer -- we hardwired the front-ends to expect all tree nodes to
start off with a `struct tree_common', which stinks because now that
approach doesn't work -- we actually need something at the beginning
of cc1_data, instead of the end.

So, that leads to another idea:

  struct cc1_data {
    /* extra stuff here */
    struct cppilb_data cd;
  };

Now, parameterize cpplib to allocate as much extra memory at the
beginning as required by the client, and just ignore it.

I think this would be very clean, even if a little upside-down.

    Neil> I feel that if I'd posted your idea as a patch, it would
    Neil> have been rejected outright.

:-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com