----- Original Message ----- 
From: "Vesa Karvonen" <vesa_karvonen@[...].com> 

>  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