-----Original Message----- [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Currie
Can anyone lend assistance in debugging the Sun regressions for Boost Preprocessor? The early access edition of the Studio 9 compiler is failing on BOOST_PP code that compiles just fine under earlier versions.
The code that's failing appears to relate to the expansion (or lack thereof) of the macros that implement BOOST_PP_WHILE. I'm continuing to investigate, but since I'm unfamiliar with what the macros are *supposed* to do, I'm hoping someone can spot the trouble more quickly than I can.
I've attached the preprocessed code from libs/preprocessor/test/control.cpp.
It looks more like a failure in the automatic recursion mechanism (all that NODE stuff that you see in the output is from the internals of the binary search on available WHILE iterations). First, what happens when you avoid automatic recursion in the test case: #include <boost/preprocessor/arithmetic/add.hpp> #include <boost/preprocessor/arithmetic/dec.hpp> #include <boost/preprocessor/control/while.hpp> #define PRED(d, state) state #define OP_1(d, state) BOOST_PP_DEC(state) #define OP_2(d, state) BOOST_PP_DEC(BOOST_PP_ADD_D(d, BOOST_PP_WHILE_ ## d(PRED, OP_1, state), state)) BOOST_PP_WHILE_1(PRED, OP_2, 10) // 0 Second, what is the result of this: #include <boost/preprocessor/control/while.hpp> BOOST_PP_WHILE // should be: BOOST_PP_WHILE_1
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Currie
Not knowing much, the first thing I'd do is play with the flags settings in boost/preprocessor/config/config.hpp to see if any of those can work around the problem.
That, combined with some futher investigation, yielded a partial solution: the newest version of the Sun needs to enable BOOST_PP_CONFIG_MSVC, in order for BOOST_PP_BITAND to work properly.
What? Does this work? #include <boost/preprocessor/logical/bitand.hpp> BOOST_PP_BITAND(0, 0) // 0 BOOST_PP_BITAND(0, 1) // 0 BOOST_PP_BITAND(1, 0) // 0 BOOST_PP_BITAND(1, 1) // 1 If it doesn't, then the Sun preprocessor is more seriously broken than I thought. The MSVC configuration is a bad configuration to have to step down too. What it fundamentally does is attempt to force things to expand that should have expanded already.
Enabling this does not cause regressions in the earlier version, at least w.r.t. Boost PP.
The test files for the pp-lib do not comprehensively test the pp-lib. If it did, there would be many more failures.
This leaves one test still failing, list.cpp. I've been unable to come up with a config combination that will clear this one up. BOOST_PP_LIST_FOLD_LEFT seems to not remove enough whitespace. I'm sure it's just a bug in Sun's token pasting (which was the cause of the other problems). I'll continue to look for a workaround.
BTW, whitespace between the ## operator and its operands is non-significant--even if there a hundred space characters in between it should still work.
I've attached preprocessor output from list.hpp, the first comes from just adding the MSVC flag, the second from adding the MSVC, EDG, and STRICT flags.
What is the output of list.cpp without any of these flags set (some of these are contradictory)?
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Currie
I've attached a patch for boost/preprocessor/config/config.hpp, in order to at least fix the most common problems the Sun Studio 9 compiler is having with BOOST_PP_WHILE, as a number of libraries are choking on this at the moment.
Before we get to this, lets try to isolate the problem a little better, but I don't have access to that preprocessor directly. Setting the MSVC and EDG/STRICT flags is contradictory and is almost guaranteed to cause a failure some time in the future--i.e. STRICT particularly implies *not* MSVC. In any case, setting the MSVC flag alone is an option (though an unfortunate one). Regards, Paul Mensonides