From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9966 invoked by alias); 16 Oct 2002 20:27:21 -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 9958 invoked from network); 16 Oct 2002 20:27:20 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 16 Oct 2002 20:27:20 -0000 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id D9C3216826; Wed, 16 Oct 2002 22:27:19 +0200 (MEST) Date: Wed, 16 Oct 2002 14:23:00 -0000 From: Michael Matz To: Tim Hollebeek Cc: Kevin Lawton , Zack Weinberg , Jamie Lokier , Subject: Re: Request of new __attribute__ for switch statements (elimination of the bounds check) In-Reply-To: <20021016131437.A25171@hollebeek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00998.txt.bz2 Hi, On Wed, 16 Oct 2002, Tim Hollebeek wrote: > > And that "switch (an_enum)" thing, also "fully populated" in the sense > > that all enumeration values are mentioned. > > Cases like that that are performance critical, not a factor of two, > and cannot be expanded to a factor of two? I don't buy it. Why should they have to be expanded to ^2? That's also syntactic sugar (because semantically not needed), and doesn't express exactly what one wants (which is a real set of values), besides cluttering up the switch statement (consider an "enum {BASE=0, OTHER=0x7fff};" which strictly would need to check two values only, whereas with your work-around would need to check 0x8000 of them). The extension of strict enums would not have application _only_ in optimizations but also in type checking. > Remember, we already have -Wswitch, and default: abort(), which are "default: abort()" is an even more hidden hint for optimization than an explicit attribute on an enum to be strict. That also can be used for optimization hint, but isn't quite like not having a default case at all (after all if you write "default: abort();" that's only a hint to the compiler that this case is extremely unlikely, whereas with an strict enum you ensure to the compiler, that non-enumerated values are _impossible_). > adequate for all but the most performance intensive cases. Sure, but I don't see, how such a meta type (strict enums) is useless, as language mean _and_ as optimization hint. C IMHO actually lacks a real set type (it's already usefull to support one-element subset variables, instead of fully featured subset vars like Pascal), and this extension, if well thought out (I don't think there are too many issues) could actually find its way to ISO C. That having said, this strict enum proposal is just hot air unless someone begins to implement it. I don't know enough about the frontends to do this currently. Ciao, Michael.