-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Sunday, August 15, 2004 1:09 PM To: boost@lists.boost.org 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