Re: # [boost] Preprocessor: compiler/library/user bug?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-09 00:51:48

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

> [...]
> >preprocessing concatenation operation results in two valid preprocessing
> >tokens.
>                                                    ^^^
> ^^^^^^
> [...]
> >BOOST_PP_CAT(other.d_,PPV_NAME(I))

How is that any different than this?

BOOST_PP_CAT(class T, 0) // class T1

My reading of the standard suggests that the code above is valid.  Operator
# acts on a parameter.  Operator ## however, acts on the replacement list
tokens.  So, assuming that CAT is implemented as follows:

#define BOOST_PP_CAT(a, b) BOOST_PP_CAT_D(a, b)
#define BOOST_PP_CAT_D(a, b) a ## b

Ultimately, you have this (since both parameters have already expanded):

BOOST_PP_CAT_D(other.d_, some_value) // assuming I == 0

Which should expand to:

other.d_ ## some_value

At this point the concatenation should occur which is not relevant to the
parameter.  (It's only relevant to the parameter to determine whether or not
the parameter itself should expand.)

other.d_some_value

That is what the result *should* be, IMO.  It is a valid concatenation of
the preprocessing token "d_" and the preprocessing token "some_value" that
yields the single, valid preprocessing token "d_some_value".  "other."
shouldn't matter anymore.

Paul Mensonides