From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27626 invoked by alias); 25 Mar 2003 10:58:04 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27615 invoked from network); 25 Mar 2003 10:58:02 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sources.redhat.com with SMTP; 25 Mar 2003 10:58:02 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h2PArhH2013933; Tue, 25 Mar 2003 11:53:43 +0100 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h2PArgKQ013932; Tue, 25 Mar 2003 11:53:42 +0100 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Jason Merrill Cc: Mark Mitchell , Matt Austern , gcc@gcc.gnu.org Subject: Re: C++: Why do we nreverse CLASSTYPE_TAGS References: <1048539747.25122.64.camel@doubledemon.codesourcery.com> From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Tue, 25 Mar 2003 11:26:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-03/txt/msg01519.txt.bz2 Jason Merrill writes: | On 25 Mar 2003 06:38:33 +0100, Gabriel Dos Reis wrote: | | > Yes. However, a linear search is done when looking for nested-types | > in decl.c:lookup_tag(). Replacing current_binding_level->tags with a | > hash-table turned out to affect CLASSTYPE_TAGS also since we do some | > random assignments here and there... | | Do we still need to use current_binding_level->tags to find types? | Shouldn't that information be in the BINDING structures now? We really | ought to unify the name lookup code. I agree 100% with you. And that is the road I took until I discovered that the changes might be too invasive for acceptance into 3.3. That is the reason why I fall back to the more conservative solution of replacing current_binding_level->tags with a hash-table, and later (i.e. mainline) unify the code. In the course of unifying the name lookup code, I discovered many lovely monstruosities :-) In fact, I think we do not need to recreate the bindings each time we push into the scope of a class; we should be able to reuse the snapshot established at popclass(). -- Gaby