From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17423 invoked by alias); 29 Apr 2009 23:33:47 -0000 Received: (qmail 17413 invoked by uid 22791); 29 Apr 2009 23:33:46 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 23:33:41 +0000 Received: from unknown (HELO delta2) ([192.168.1.50]) by c60.cesmail.net with ESMTP; 29 Apr 2009 19:33:22 -0400 Received: from 5ac91543.bb.sky.com (5ac91543.bb.sky.com [90.201.21.67]) by webmail.spamcop.net (Horde MIME library) with HTTP; Wed, 29 Apr 2009 19:33:22 -0400 Message-ID: <20090429193322.q7i3jg40is84owsw-nzlynne@webmail.spamcop.net> Date: Thu, 30 Apr 2009 05:56:00 -0000 From: Joern Rennecke To: Esben Mose Hansen Cc: gcc@gcc.gnu.org Subject: Re: gcc-in-cxx update / multi-targeted gcc MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg00803.txt.bz2 > On Wednesday 29 April 2009 12:47:04 Joern Rennecke wrote: >> Something which I miss in C++ is a way to declare that a function uses >> an integral type to pass an enum value (in arguments or return value), >> and then at function definition time only check that the integral type >> is sufficently large to hold the enum, and then for type checking purpos= es >> treat the parameter / return value as if it had been declared as this en= um. Esben Mose Hansen wrote: > This is exactly N2764, which should be part of C++0x --- at least it=20=20 > seems to be in the draft around p.149. But not part of gcc 4.4.=20=20 > unfortunately. > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf That is closely related, but it's not quite the same. For a multi-targeted gcc, we'd want generic code to operate on integral types that correspond to enum values defined by the various targets - but these will define these enums differently. If the generic code was in a library, and compilers for the different targets were built separately, then N2764 would work. However, when linking multiple targets together, enums with the same name for different targets are different types, so they can't all be the same type as the type used by the generic code. This is why I would like the generic code to use a separate type which is assignment-compatible with any of these enums if the enums definition is visible.