From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15680 invoked by alias); 24 May 2005 08:32:33 -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 15592 invoked by uid 22791); 24 May 2005 08:32:19 -0000 Received: from colo.khms.westfalen.de (HELO colo.khms.westfalen.de) (213.239.196.208) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 24 May 2005 08:32:19 +0000 Received: from khms.vpn ([10.172.192.2]:59257 helo=khms.westfalen.de) by colo.khms.westfalen.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1DaUpP-0004G8-5o for gcc@gcc.gnu.org; Tue, 24 May 2005 10:31:55 +0200 Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.50) id 1DaUpL-0000vh-33 for gcc@gcc.gnu.org; Tue, 24 May 2005 10:31:51 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh15 R/C435); 24 May 2005 10:19:09 +0200 Date: Tue, 24 May 2005 15:03:00 -0000 From: kaih@khms.westfalen.de (Kai Henningsen) To: gcc@gcc.gnu.org Message-ID: <9XSy01O1w-B@khms.westfalen.de> In-Reply-To: <4292C8C9.9040400@codesourcery.com> Subject: Re: Compiling GCC with g++: a report MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii References: <4292C159.4050906@codesourcery.com> <877jhpkut9.fsf@codesourcery.com> <877jhpkut9.fsf@codesourcery.com> <4292C8C9.9040400@codesourcery.com> X-No-Junk-Mail: I do not want to get *any* junk mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-SW-Source: 2005-05/txt/msg01297.txt.bz2 mark@codesourcery.com (Mark Mitchell) wrote on 23.05.05 in <4292C8C9.9040400@codesourcery.com>: > Zack Weinberg wrote: > > Mark Mitchell writes: > > > > [snip stuff addressed elsewhere] > > > >>I agree with the goal of more hiding. > >> > >>You can do this in C by using an incomplete structure type in most > >>places, and then, in the files where you want the definition visible, > >>defining the structure to have a single field of the enumerated > >>type. That is a little messy, but it is C++-compatible. (In fact, in > >>ISO C++, without the additions presently in the WP, you can't do > >>better; forward declarations of enums are still not allowed.) > > > > > > Doesn't work, at least not as a drop-in replacement; you can't pass an > > incomplete structure by value. We do do this in places where there's > > a real structure that can be passed around by pointer... > > Good point; yes, you would have to pass a pointer. I guess you could > create a singleton representative of each value in the enum, and pass > them around, but I agree that's getting pretty ugly. Of course, the > problem with "unsigned int" is that it is a complete type, and people > can accidentally pass in "7", even if there's no such enumeral. You > really want forward-declared enums, but you haven't got them; it may be > you just lose. :-( What I've done, in a similar situation, was to declare a complete structure encapsulating the value - this at least makes sure you need to acknowledge the structure whenever you access the value. Plus, I've added inline functions for accessing the value, so those places don't need to know the structure details either. This makes it fairly type safe, and you can grep for all kinds of uses (including people who naughtily access the structure contents directly). MfG Kai