Re: [boost] [binary-int] pre-release available

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