Boost logo

Boost :

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-09-10 04:52:43


On 9/10/05, Paul Mensonides <pmenso57_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk