a nifty feature for c preprocessor

David Brown david.brown@hesbynett.no
Sun Jan 1 12:58:00 GMT 2012


On 31/12/11 10:44, R A wrote:
>
> alright, here's another example why eval is a good idea:
>
> #define A           17 #define B           153 #define N1
> ((A + B)/2)  /* intended was (17 + 153)/2 */
>
> #undef  A #define A           230 #define N2          ((A + B)/2) /*
> intended was (230 + 153)/2 */
>
> printf("%u %u", N1, N2);
>
>
> sure, you can assign N1 to a static const, say N1_var, then invoke
> that in when printf is finally called. or simply print N1, then after
> the undef print N2. but what if we have to use both N1 and N2 in the
> same conditional expression?? everybody should be aware by now that
> there's a lot of ugly dependencies in cpp.
>

The best idea for something like this would be to use a static const (I 
don't know why you dismissed that).  Undefining and redefining your 
macros like this is almost always a bad idea - it is far easier to 
understand your program, and to write correct code, if macros mean one 
thing and one thing only.

> but for a *fairly complex*(1) conditional directives, spanning
> several files, you have to call the macros all at the same time and
> not one one-by-one. to get around it (if possible) is to employ an
> even more complex system of defs and conditionals... or you can use
> external scripts to generate the codes. but like i said, these could
> just be small snippets of codes, where having scripts is
> un-minimalistic. eval takes away all the ugliness.
>
> (1) by fairly complex, i mean one that doesn't really merit a
> script/macro processors to be written.
>
> alright, if i can't convince the developers, would a maintainer (or
> anybody that knosw their way around libcpp) please help me out on how
> to get started my port for the feature... i actually don't like the
> idea of writing a plugin.
>



More information about the Gcc mailing list