From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-04-18 01:40:23
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