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:

| On Mon, 2003-03-24 at 10:10, Gabriel Dos Reis wrote:
| > 
| > Hi,
| > 
| >   While working for a conservative solution (i.e. minimal patch) for
| > reducing excessive compile-time in GCC-3.3/cc1plus, I noted that we
| > are nreverse()ing the list of class-types or enums declared at a
| > class-scope in cp/class.c:unreverse_member_declarations().
| > 
| > As far as I can see, reversing the CLASSTYPE_TAGS is not necessary
| > since the whole purpose of CLASSTYPE_TAGS is serving as a database for
| > name lookup.
| > 
| > What am I missing?
| 
| Nothing, really.  But:
| 
| (1) The order there may matter when doing template instantiation.  It
| makes sense to instantiate the CLASSTYPE_TAGS in the order they appeared
| in the source.

I thought of that.  But, when doing template instantiation, the order
in which the nested (possibly template) *type-names* are declared does not
matter.  I'm not that saying it does not make sense to instantiate in the
same order, I'm saying that that order does not matter.  

| (2) In general, the IL ought to represent the source; source order here
| makes sense.

While it would be nice to output something that follows as closely as
possible the original  program source, there is no requirement in this
specific case that the nested *type-names* be output in the same order.

| (3) nreverse is pretty cheap.

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. 


-- Gaby