From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4664 invoked by alias); 22 Nov 2002 18:06:19 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 4635 invoked from network); 22 Nov 2002 18:06:16 -0000 Received: from unknown (HELO smtp-relay-2.adobe.com) (192.150.11.2) by sources.redhat.com with SMTP; 22 Nov 2002 18:06:16 -0000 Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id gAMI35kw017740 for ; Fri, 22 Nov 2002 10:03:05 -0800 (PST) Received: from iplan-mn.corp.adobe.com (iplan-mn.corp.adobe.com [130.248.25.5]) by inner-relay-1.corp.adobe.com (8.12.3/8.12.3) with ESMTP id gAMI68KX009703 for ; Fri, 22 Nov 2002 10:06:08 -0800 (PST) Received: from mn-eljaypc.adobe.com ([130.248.188.158]) by iplan-mn.corp.adobe.com (Netscape Messaging Server 4.15 mn Jul 11 2001 16:32:57) with ESMTP id H5ZOY700.Q85; Fri, 22 Nov 2002 12:06:07 -0600 Message-Id: <4.3.2.7.2.20021122114945.00b5eb00@iplan-mn.corp.adobe.com> X-Sender: eljay@iplan-mn.corp.adobe.com Date: Fri, 22 Nov 2002 10:06:00 -0000 To: "Buddy Lott" , From: Eljay Love-Jensen Subject: RE: CPP (preprocessor) quandry In-Reply-To: <583E84A77A2FCB4F967E6CD9B0CA4AF74E4905@nt-server.kreuter> References: <4.3.2.7.2.20021122105625.00b525e8@iplan-mn.corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SW-Source: 2002-11/txt/msg00165.txt.bz2 Hi Buddy, The macro wraps the data type in a struct, so as to reduce namespace pollution. In particular, it avoids... typedef enum {a,b,c} EnumWhatever; ...such that a, b, c and EnumWhatever now reside in the global (or current) namespace. I have found a GCC-centric solution. But (unfortunately) the code needs to run on other compilers. #define $MkEnum(name$, enum$...) \ struct name$ {\ typedef enum { enum$ } Type;\ Type m;\ explicit name$ (Type in) : m(in) { }\ operator Type () const { return m; };\ } NOTE: local convention dictates that $ is used to prefix macros (function macros or simple substitution), and $ suffix for the macro's parameters. The $ is digestable by all the preprocessors / compilers we care about. Less chance of spurious macro vs. local identifier collision. Something similar to this trick was proposed / introduced by Stroustrup in his C++ Programming Language (3rd and Special editions). Not the macro part, but the wrapping of a POD in a struct to have somewhat stronger type safety. Getting that stronger type safety is the ultimate purpose of the macros; the macros serve to reduce repetitive typing -- and thus reduce mistakes and simplify maintenance. A better solution would be to use a language that has this facility native. Stroupstrup told me (paraphrased), "No one is stopping you from writing your own language." (I think he was a little tired of hearing a bazillion requests and suggestions for how to "improve" C++.) Sincerely, --Eljay (I hate macros) At 12:43 PM 11/22/2002 -0500, Buddy Lott wrote: >I can't think of a way to get around this, but maybe if you explain what >purpose this solves (in other wordes, why use the macro) I could think >of a way to accomplish the same thing. > >One what that comes to mind: > >Typedef enum { a,b,c} EnumWhatever; >MkFoo(Whatever)