----- Original Message -----
From: "Vesa Karvonen" <[EMAIL PROTECTED]>
> The basic idea is that the keywords '__l_paren__', '__r_paren__' and
> '__comma__' could be used in place of '(', ')' and ',', respectively. The
> above example would now become:
>
> #define ID(x) x
> ID( __l_paren__ )
> ID( a __comma__ b )
> ID( __r_paren__ )
>
> and it would expand into:
>
> __l_paren__ a __comma__ b __r_paren__
I like the idea. (Though I'd prefer __lparen__ and __rparen__.) What about
__hash__ and __hashhash__? It is currently illegal for # to appear in a
function-like macro replacement list unless it leads a parameter. In which
case, it is the stringizing operator. So, instead you have to do this...
#define HASH() HASH_I
#define HASH_I #
#define HASH_HASH CAT(HASH(), HASH())
...in order to produce the tokens # and ##.
Commas and parentheses are much more of a problem though, I agree.
Also, and perhaps more importantly than any of these "punctuation" operators:
__newline__
...which would have no effect on compilation but would insert newlines into
preprocessing output.
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.
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?
Regards,
Paul Mensonides
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
