Aleksey Gurtovoy wrote: > Paul Mensonides wrote: >>> Yep, they do - that's why I named it "BOOST_PP_REPEAT + >>> BOOST_PP_SEQ_ELEM bug". >> >> That is what I figured, but I wanted to make sure that the (a, b, c) >> wasn't causing a problem--which it shouldn't be anyway. I'll look >> at this later when I have time to install VC6 on my other computer. > > That would be much appreciated.
Okay, this is "fixed," but before you update, this is the reduction of the problem. First, it has nothing to do with BOOST_PP_REPEAT per se. Rather it is the kind of instability that I mentioned before relative to IS_UNARY, since SEQ_ELEM does a similar kind of thing. Take a look: #include <boost/preprocessor/seq/elem.hpp> #define X() ... #define A(seq) BOOST_PP_SEQ_ELEM(0, seq) #define B(seq) (BOOST_PP_SEQ_ELEM(0, seq)) #define C(seq) ID( BOOST_PP_SEQ_ELEM(0, seq) ) #define D(seq) ID(( BOOST_PP_SEQ_ELEM(0, seq) )) #define ID(x) x A( (X)(Y) ) // X B( (X)(Y) ) // (X) C( (X)(Y) ) // X D( (X)(Y) ) // 0 The last one is wrong. It should expand to (X). This should be fixed now, but it illustrates the kind of encapsulation issues that I was referring to before. As far as the other bug is concerned, here is the reduction of the problem: // entire file... #define M() M VC6 expects to find the open parentheses of a macro invocation, but instead it finds EOF. There is nothing that I can do to fix this one. However, VC7 seems to have fixed this problem, at least. Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
