RE: [boost] [preprocessor] BOOST_PP_IS_UNARY for Borland

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2004-08-15 16:37:01

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Daniel James

> 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

I like it, but how about instead (in the interest of reuse):

#include <boost/preprocessor/detail/split.hpp>
#include <boost/preprocessor/punctuation/comma.hpp>
#include <boost/preprocessor/punctuation/paren.hpp>
#include <boost/preprocessor/tuple/eat.hpp>

#define IS_NULLARY(x) \
    BOOST_PP_SPLIT(1, IS_NULLARY_C x BOOST_PP_COMMA() 0) \
    /**/
#define IS_NULLARY_C() \
    ~, 1 BOOST_PP_RPAREN() \
    BOOST_PP_TUPLE_EAT(2) BOOST_PP_LPAREN() ~ \
    /**/

#define IS_UNARY(x) IS_NULLARY(IS_UNARY_C x)
#define IS_UNARY_C(x) ()

#define IS_BINARY(x) IS_NULLARY(IS_BINARY_C x)
#define IS_BINARY_C(x, y) ()

Can someone try these on the IBM preprocessor and the Sun preprocessor as well?

> So, if this is used as for borland, could these marcros be 
> made 'public'?

I see no problem with adding the functionality, but the macros still cannot
safely be made public.  On other compilers (besides Borland), their use causes
stability problems.  Using something like the above doesn't help (it would
actually be slightly worse) because of the reliance on intermediates in the
argument--which requires that expansion order proceed as it should (which is not
the case on some preprocessors).

> 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?

It is already possible because the identifier is known.  Lack of a nil sequences
(until we get placemarkers) was a conscience decision.  An important property of
sequences is the ability to directly append.  By definition, if A and B are both
sequences, then A B is also a sequence.  There is obviously a need for nil
sequences, but for now, the use of a temporal nil is the better solution.

Regards,
Paul Mensonides