Re: [boost] Re: missing ## ... juxtaposition?

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-12-03 02:38:29

Dan W. writes:
> I reported earlier that there are some boost files where it appears that
> ##'s are missing; which with the Digital Mars compiler results in a space
> being inserted; eg.:
>
> in file "...boost\mpl\list.hpp":
> #   define MPL_AUX_LIST_HEADER
> BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp /**/
> which I was able to work-around by adding the ##, such as:
> .....,BOOST_MPL_LIMIT_LIST_SIZE)##.hpp /**/
>
> Paul Mensonides replied:
>  >The compilers are wrong to insert a space, and a concatenation here is
> undefined
>  >behavior.  A better way to fix it would be to try this:
>  >
>  >#define MPL_AUX_LIST_HEADER \
>  >    MPL_AUX_LIST_HEADER_I(BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE))
\
>  >    /**/
>  >#define MPL_AUX_LIST_HEADER_I(name) name.hpp
>
> Subsequently, I exchanged messages at the Digital Mars forum. I am no
> expert in C++ myself, so I'm just trying to be helpful in solving this
> problem by acting as dumb messenger. I'll just copy and paste a summary of
> the DM forum dialog below.
>
> --------------------------------------------------------------------------
------------
>  > In article <bq8u65$obq$1_at_[hidden]>, Walter says...
>  >I don't see how that derives from the spec. The only token concatention
>  >allowed by the spec is with ##, extra whitespace should be quite
irrelevant.
>  >## is defined as token concatenation, so I don't see how that is
undefined.

[...]

>  >The separator inserted by dmc is to make the preprocessor work right, it
>  >isn't easilly removed. I don't really understand why boost seems to want
to
>  >rely on the 'juxtaposition-equals-concatenation' kludge, the ## operator
was
>  >added to Standard C specifically to move away from that practice.
> --------------------------------------------------------------------------
------------
> Maybe if someone could paste the section of the Standard dealing with
this,
> I'd much appreciate it.

16.3.3 [cpp.concat] para 3 (my emphasis):

"For both object-like and function-like macro invocations, before the
replacement list is reexamined for more macro names to replace, each
instance of a ## preprocessing token in the replacement list (not from an
argument) is deleted and the preceding preprocessing token is concatenated
with the following preprocessing token. *If the result is not a valid
preprocessing token, the behavior is undefined*. [...]"

In the case in question, ")." is definitely not a valid preprocessing token
(it's two).

Aleksey