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":
> 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 \
> > /**/
> >#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
> >## is defined as token concatenation, so I don't see how that is


> >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
> >rely on the 'juxtaposition-equals-concatenation' kludge, the ## operator
> >added to Standard C specifically to move away from that practice.
> --------------------------------------------------------------------------
> Maybe if someone could paste the section of the Standard dealing with
> 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).


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