* Note that I don't know of a single preprocessor that actually handles whitespace correctly in all cases.
Damn, I know I had that right in Wave at some point. Must have broken it later... And apparently there are no tests in Wave verifying this is functioning as expected.
I'll fix both things asap.
Note that there is only one way that the lack of proper handling can effect the semantics of a program: stringizing. Further, it must internal whitespace because stringizing removes leading and trailing whitespace and condenses adjacent internal whitespace by definition-- which you can get because the normal whitespace condensation happens in an earlier separate phase:
#define A(x) 1 x 3
A(2) // 1 2 3 A( 2 ) // 1 2 3
This is the only place in Wave I found so far where the whitespace is not preserved, I get A( 2 ) // 1 2 3 I'll see what I can do, though.
When stringized these both result in "1 2 3". However, something like this is where things change:
#define B(x) (1)x(3)
STRINGIZE(B(3)) // "(1)3(2)" STRINGIZE(B( 3 )) // "(1) 3 (2)" -- aha! different semantics
Well, that depends on how you define the STRINGIZE() macro. It might not expand the B() at all :-P In any case, this is handled properly in Wave.
Other than scenarios like that, it makes no effective difference.
Sure. Regards Hartmut --------------- http://boost-spirit.com