Re: C++: Why do we nreverse CLASSTYPE_TAGS

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark at codesourcery dot com> writes:

| > I do not doubt that nreverse() is cheap -- the point here isn't to win
| > some possible micro-seconds.  It is about datatype structures,
| > associated algorithms and operations.  The main point being that
| > it makes sense to use a hash-table for serving the purpose of
| > CLASSTYPE_TAGS, but then, it does not make sense to maintain a given
| > order or to reverse that order.  That is the fundamental reason for my
| > asking the original question. 
| 
| OK, let's think in the broader context.
| 
| There should ideally be one data structure: a list of the members
| declared in the class, with, if there are lots of members, a hash table
| to index those things.
| 
| You need both the list and the dictionary; you want to be able to do
| things like iterate through the list of FIELD_DECLs in order, and also
| to find them quickly.

Right.

| I don't think CLASSTYPE_TAGS should need to exist at all; everything
| that you can find there should also be something you can find on
| TYPE_FIELDS.

OK.

| So, I'd suggest (1) eliminate CLASSTYPE_TAGS, and (2) add a hash table
| for TYPE_FIELDs if there are lots of members.

OK, I'll experiment with that approach.  What threasold would you put
for "lots"?

Another case I'm thinking of is when set CLASSTYPE_TAGS with
current_binding_level->tags, although I do not believe that would be a
real obstacle.

Thanks,

-- Gaby