Re: [boost] ATTN: All Developers Interested in Boost.Preprocessor

From: Vesa Karvonen (vesa_karvonen_at_[hidden])
Date: 2003-04-30 13:08:44

Paul Mensonides:
>Vesa Karvonen:
>>    __l_paren__ a __comma__ b __r_paren__
>
>I like the idea.  (Though I'd prefer __lparen__ and __rparen__.)

__lparen__ and __rparen__ are fine with me.

>What about __hash__ and __hashhash__? [...]

These look very reasonable to me.

>Also, [...] __newline__

__newline__ could be very useful for making the output of macro expansion 
readable. Personally, however, I don't mind that generated code wouldn't be 
readable. Ideally one should never need to look at the generated code except 
perhaps during the development of the generator. Therefore, I find that 
__lparen__, __rparen__ and __comma__ would be strictly more important for 
the purpose of code generation.

There is also a potential problem with __newline__. According to the 
standard, newline characters are handled before macro replacement. If 
nothing else, this could potentially make it more difficult to specify and 
defend the proposal. Note that I'm not saying that I don't like __newline__ 
- quite the opposite. I'm just noting that it might be more difficult to 
specify and defend.

>One question Vesa, what happens here:
>
>#define STRINGIZE(x) PRIMITIVE_STRINGIZE(x)
>#define PRIMITIVE_STRINGIZE(x) #x
>
>STRINGIZE(__comma__)           // ?
>PRIMITIVE_STRINGIZE(__comma__) // ?
>
>I'm assuming that, because they aren't macros, they should not "expand" 
>before
>stringizing.

The way I would see it, the above should produce:

"__comma__"
"__comma__"

What I mean, is that the simplest way to specify this extension would be 
that the alternative tokens would be converted to their traditional form 
strictly after macro replacement (or more accurately, strictly after the 
phase that currently does macro replacement, but strictly before any other 
phase). In other words, the macro replacement phase wouldn't recognize them 
at all - or, at most, it would disallow redefining them as macros (the names 
of the alternative tokens are already reserved).

Of course, this could sometimes make generated code a bit uglier. For 
example, suppose that you pass generated code to an assertion macro that 
stringizes the code so that it can be displayed when the assertion is hit. 
Personally, I don't see this as a major problem.

>Finally, if C++ gets C99's inline _Pragma.  Some standard pragmas could be 
>used
>to generate these tokens:
>
>_Pragma("STDC TOKEN ,")
>
>Which could be shortened at will to:
>
>#define COMMA _Pragma("STDC TOKEN ,")
>
>Thoughts?

I'm not sure that I like it very much. If nothing else, then it should be 
easier to manipulate simple tokens like __comma__ than a token sequence like 
_Pragma("STDC TOKEN ,"). Also, is it really regular practise to introduce 
pragmas that are syntactically significant in this way? Most, if not all, 
pragmas seem to be for controlling the behaviour of code generation rather 
than controlling syntax or especially inserting tokens. Although I haven't 
been looking at the sources of C compilers lately, I think that it might be 
significantly more difficult to support a pragma like the above in a 
compiler.

...

Finally, I think that this new translation phase should be completely 
contained in the preprocessor.

-Vesa

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail