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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-09-10 04:23:07

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Matt Calabrese

> Sorry for the delay. I wanted to do this on Monday but I've 
> been busy all week. After that reply, Paul emailed me his 
> take on a solution using his Chaos preprocessor library which 
> influenced some changes in design for my implementation using 
> boost, though I did alter the logic a bit. Since I now allow 
> arbitrary groupings of bits whose lengths are 8 or below, 
> converting to octal is actually simpler than converting to 
> hex, so the macro now yields an octal value. In addition to 
> that, I added two extra forms: 
> BOOST_BINARY_LITERAL_D and BOOST_SUFFIXED_BINARY_LITERAL_D, 
> which take a an extra parameter at the start of the list 
> which represents the while recursion depth (for more 
> efficient use when nested inside another while call). 
> Originally I wanted to make _S versions as well to account 
> for the BOOST_PP_SEQ_FOLD_LEFT recursion depth "s," however I 
> ran into some troubles since Boost.Preprocessor concatenates 
> "s" onto BOOST_PP_SEQ_FOLD_LEFT_ with ## as opposed to 
> BOOST_PP_CAT for SEQ_CAT and SEQ_TRANSFORM. This means that 
> my macro call to deduce the recursion depth never expands 
> prior to concatenation.

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.

As far as introducing both an _S and a _D suffixed variation--don't bother.
Just deduce one of them (or both), but it isn't worth cluttering the interface
with multiple variations.  The pp-lib itself has this same issue in a few
places, and I find my "solutions" obnoxious at best (e.g.
BOOST_PP_REPEAT_FROM_TO_D_ ## z).  In fact, this is one of the major design
flaws of the pp-lib.  Originally, it was the best I could do.  Now, I can do
better, but not without dropping support for quite a few
preprocessors--including heavily used ones like VC.  [Chaos, as usual, doesn't
suffer from this problem.]

A couple of other things...

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?

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)

Regards,
Paul Mensonides

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Daniel James
> Sent: Sunday, August 15, 2004 1:09 PM
> To: boost_at_[hidden]
> Subject: [boost] [preprocessor] BOOST_PP_IS_UNARY for Borland
> 
> I've written an implementation of BOOST_PP_IS_UNARY which 
> works for Borland, and hopefully any other preprocessors 
> which the current implementation doesn't. It is:
> 
>      #define EAT2(x,y)
> 
>      #define IS_UNARY_CHECK(x) ~, 1 BOOST_PP_RPAREN() \
>          EAT2 BOOST_PP_LPAREN() ~
> 
>      #define IS_UNARY(x) IS_UNARY_1(IS_UNARY_CHECK x, 0)
>      #define IS_UNARY_1(x, y) IS_UNARY_2(x, y)
>      #define IS_UNARY_2(x, y) y
> 
> For a non-unary argument, the expansion is simple:
> 
>      IS_UNARY(x)
> =>  IS_UNARY_1(IS_UNARY_CHECK x, 0)
> =>  IS_UNARY_2(IS_UNARY_CHECK x, 0)
> =>  0
> 
> For a unary argument, it expands like this (I might have got 
> the expansion order slightly wrong but, hopefully, this 
> illustrates how it
> works):
> 
>      IS_UNARY((x)y)
> =>  IS_UNARY_1(IS_UNARY_CHECK(x)y), 0)
> =>  IS_UNARY_2(~, 1 BOOST_PP_RPAREN() EAT2 BOOST_PP_LPAREN() 
> ~y, 0) =>  IS_UNARY_2(~, 1) EAT2(~y, 0) =>  1
> 
> The same technique can be used for BOOST_PP_IS_NULLARY and 
> BOOST_PP_IS_BINARY.
> 
> So, if this is used as for borland, could these marcros be 
> made 'public'? Also, with a full working BOOST_PP_IS_UNARY, I 
> think it should be possible to make BOOST_PP_SEQ_NIL act as 
> an empty sequence, if I write a patch to do that would it be accepted?
> 
> Daniel