Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk