Boost logo

Boost :

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:
>STRINGIZE(__comma__) // ?
>PRIMITIVE_STRINGIZE(__comma__) // ?
>I'm assuming that, because they aren't macros, they should not "expand"

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


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
>to generate these tokens:
>_Pragma("STDC TOKEN ,")
>Which could be shortened at will to:
>#define COMMA _Pragma("STDC TOKEN ,")

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


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


The new MSN 8: smart spam protection and 2 months FREE*

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