Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-04-30 10:43:51

----- Original Message -----
From: "Vesa Karvonen" <vesa_karvonen_at_[hidden]>

> 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()) 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:


...which would have no effect on compilation but would insert newlines into
preprocessing output.

One question Vesa, what happens here:


STRINGIZE(__comma__) // ?

I'm assuming that, because they aren't macros, they should not "expand" before

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 ,")


Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at