This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: CPP (preprocessor) quandry


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)

> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org]
On
> Behalf Of Eljay Love-Jensen
> Sent: Friday, November 22, 2002 12:17 PM
> To: gcc-help@gcc.gnu.org
> Subject: CPP (preprocessor) quandry
> 
> Here's a simplified example of my quandry:
> #define MkFoo(y) typedef y Foo
> 
> Users were happy with this solution, doing things like...
> 	MkFoo(unsigned char);
> ...or...
> 	MkFoo(signed long int);
> ...as they needed.
> 
> But then one day, a programmer needed this.  But the following is No
> Good...
> 	MkFoo(enum {a,b,c});
> ...since the preprocessor thinks the comma belongs to it.
> 
> So the usual way of embedding commas as a macro parm is by another set
of
> parens:
> 	MkFoo((enum {a,b,c}));
> 
> However, that expands to...
> 	typedef (enum {a,b,c}) Foo;
> ...which is still No Good.
> 
> What is the preprocessor trick to strip out the extra parens?
> 
> Or is there an inverse of stringification (passing the parm in as a
quoted
> string and then stripping the quotes would be acceptable, if
possible)?
> 
> Don't suggest templates.  Not appropriate for this code base.
> 
> Thanks,
> --Eljay
> (I hate macros.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]