-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Calabrese
After using AUTO_REC to deduce the recursion depth and pass it to an _S form of the BINARY_LITERAL macro, just as I am doing with the BINARY_LITERAL and BINARY_LITERAL_D macros with DEDUCE_D, I was getting errors concerning the concatenation onto BOOST_PP_SEQ_FOLD_LEFT_ for the S form from TRANSFORM. Again, though, this may be do to my own misunderstanding of the preprocessor, but I believed it wasn't working because TRANSFORM called SEQ_FOLD_LEFT_S via a direct ## operation as opposed to using CAT and was concatenating the macro I was using before it was expanded. Correct me if this was an improper assumption and if there wasa fault in my own doing.
(Hmmm. I wonder why I don't have a DEDUCE_S. I'll fix that; it must have been an oversight.) The library typically directly concatenates those arguments. I.e. it assumes that they are already expanded before entry to the macro. There are several reasons for this, mostly related to encapsulation on broken preprocessors (avoiding CAT uses). In any case, what you need is a delay. Instead of #define A() SEQ_TRANSFORM_S(DEDUCE_S(), ...) ...use... #define A() B(DEDUCE_S()) #define B(s) SEQ_TRANSFORM_S(s, ...) This *should* work, but the possibility exists that it won't (on VC, see below).
1) Is there a reason why you're rolling your own COMPL instead of using
BOOST_PP_COMPL? Did it fail to work correctly for some reason?
Yes. If I replace that code with a call to BOOST_PP_COMPL, at least in VC++ 7.1 which is what I was testing it on, I was getting errors. Try it out by just replacing the code with a call to BOOST_PP_COMPL. If there is something I am doing wrong, please tell me.
It isn't you. You've just run into one of the many ways in which VC's preprocessor is broken. It is probably better to leave your workaround in place, because changing the library implementation is likely to break code. VC has a remarkable tendency to do everything out of order--picking up things at later times that should have been done far earlier. This makes that preprocessor *extremely* difficult to work with for anything that relies on expansion order. The pp-lib does do this, of course, but it bends over backward to support VC as well as it does (the pp-lib source is, IMO, more workaround than concept).
2) The pp-lib already has an BOOST_PP_IS_NULLARY. However, it is not a [...]
Perhaps then I should change back to the less-elegant yet possibly more portable way I was doing it which did not use IS_NULLARY or IS_UNARY concepts -- from the 2nd out of the 3 files I posted (binary_literal.hpp), unless you have a better solution?
That might be a good idea. IS_NULLARY and similar ilk are not as stable across preprocessors as other library primitives. They are perfectly stable on non-fundamentally-broken preprocessors, of course. However, even with the workarounds, they aren't totally stable on VC and MW < 9. (It is difficult to get anything that relies on expansion order stable on these two preprocessors particularly.) Regards, Paul Mensonides