On 9/10/05, Paul Mensonides <pmenso57@comcast.net> wrote:
I'm not sure what you mean here. Can you elaborate with a small example? My immediate guess at what you're referring to is something like ABC_ ## MACRO() where MACRO() isn't expanding, but I may be misreading it.
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. 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. 2) The pp-lib already has an BOOST_PP_IS_NULLARY. However, it is not a
documented interface because it isn't portable to all (broken) preprocessors. It is, however, hacked up with workarounds for VC and older versions of Metrowerks. It should be safe to use on most preprocessors. However, the preprocessors where it won't work (that I know of) are IBM's, Sun's, and Borland's. Borland's separate command line preprocessor can handle it, but the preprocessor integrated into the compiler itself has a serious bug that prevents it. I do have an alternative implementation, thanks to Daniel James, that will work on Borland's preprocessor, but it isn't integrated into the pp-lib because IBM, Sun, and Borland all currently share the same configuration. (see quote below)
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? -- -Matt Calabrese