From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-01-25 15:11:43
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Arkadiy Vertleyb
> Is BOOST_PP_SEQ_ENUM broken?
No, but VC is. :)
> I can't use it with VC71.
It works on VC6, VC7, and VC7.1 on my system. E.g.
BOOST_PP_SEQ_ENUM((x)(y)(z)) // x, y, z
> expands to something like:
> and stops here, probably because of the space.
How are you deriving the sequence that you pass to SEQ_ENUM?
> Shouldn't the current definition:
> # define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_,
> BOOST_PP_SEQ_SIZE(seq)) seq
> be replaced with something like:
> #define BOOST_PP_SEQ_ENUM(seq)
No, the two should be equivalent. I suspect that you've ran afoul of VC's
serious expansion order problems. I.e. the sequence that is passed is created
by other macros that VC hasn't expanded yet (but should have), so when it gets
to BOOST_PP_SEQ_ENUM_3, it looks some like this:
It then doesn't expand SEQ_ENUM_3, but does expand MACRO. In other words, the
problem is likely something that has nothing to do with SEQ_ENUM, but is a
problem elsewhere. In any case, the library strives to try to protect users
from this VC problem, but it cannot do it in total because the problem ties
implementation details from macro to macro (i.e. it is an encapsulation
nightmare). The first attempt to "fix" it in this situation would be to say
(for VC only):
#define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_SEQ_ENUM_I((seq))
#define BOOST_PP_SEQ_ENUM_I(arg) BOOST_PP_SEQ_ENUM_II ## arg
#define BOOST_PP_SEQ_ENUM_II(seq) \
BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, BOOST_PP_SEQ_SIZE(seq)) seq \
If you do this, does it work correctly? (BTW, I realize that the concatenation
is undefined behavior.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk