This is the mail archive of the 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

Mark Mitchell wrote:-

> 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.

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

Are you really sure you want the extra headaches with toplev.c etc.,
and the other things your approach entails?

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

> Tying cpplib to gcc too closely is bad.

I fully agree, and have deliberately kept it too a bare minimum.  I
prefer the patch to what you describe.  What do others think?

Alternatively, we can just copy the structure, make the enum a char in
cpplib, and be careful to keep them in sync [or is that effectively
what you're saying? :-)]


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