[Freetype] Re: Summary of ANSI preprocessor trouble..

[Werner LEMBERG]

> Here's a short summary of the situation regarding the infamous
> pre-processor concatenation problem. I hope it clarify things..
> 
> > 
> > Apparently, macros are not expanded for some compilers before
> > concatenation.  For example,
> > 
> >   #define FOO xxx
> >   #define BAR FOO ## yyy
> > 
> > gives `FOOyyy' instead of `xxxyyy'.
> > 
> 
>   - lexems are formed by _any_ suite of contiguous characters
>     that are not whitespace !! So #include <FOO/xxxx> should normally
>     never substitute, even though it does in a number of cases..

This is special.  Within #include, there is no macro expansion if it
is enclosed with < > or " ".

>   - when either '#' or '##' is used, macro substitution of the
>     arguments does _not_ happen. This explains the "FOOyyy"
>     thing

Correct.

>   - when lexem concatenation is used, the whitespace surrounding the "##"
>     is discarded. which means that
> 
>        #define  z x ## y
> 
>     will result in "z xy"

Correct.  The same for #x: whitespace before and after `x' is
discarded.

>     A FEW ANSI C COMPILERS DO NOT RESPECT THIS RULE. To my
>     knowledge, these are "Win32-LCC" (which comes with its own buggy
>     CPP), and a beta version of gcc (I believe that the C
>     pre-processor has been completely rewritten as a library for the
>     upcoming gcc 3.0, maybe this explains the bugs)
> 
>     this means that #define z x ## y gives "z x y" or something
>     similar with these..

Oops!  This would be unfortunate, and I had to undo some
`beautifications'...  Please tell me.


    Werner