-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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. #include <boost/preprocessor/seq/enum.hpp> BOOST_PP_SEQ_ENUM((x)(y)(z)) // x, y, z
It expands to something like:
BOOST_PP_SEQ_ENUM_3[space](x)(y)(z)
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) BOOST_PP_SEQ_CAT((BOOST_PP_SEQ_ENUM_)(BOOST_PP_SEQ_SIZE(seq))(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: BOOST_PP_SEQ_ENUM_3 MACRO() 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): #include <boost/preprocessor/seq/enum.hpp> #undef BOOST_PP_SEQ_ENUM #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.) Regards, Paul Mensonides