[boost] [preprocessor] BOOST_PP_IS_UNARY()

Subject: [boost] [preprocessor] BOOST_PP_IS_UNARY()
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-04-04 11:06:30

Hello all,

Do you know what are the drawbacks of using BOOST_PP_IS_UNARY()? If
you have used it, what is your experience with its portability?

BOOST_PP_IS_UNARY() is *not* part of the Boost.Preprocessor public API
as it is #defined in boost/preprocessor/detail/is_unary.hpp. However,
Boost.Preprocessor, Boost.Typeof, and Boost.Spirit seem to use
BOOST_PP_IS_UNARY() at least internally:

$ find /usr/include/boost/ -name "*.[hc]pp" -exec grep -Hn
"BOOST_PP_IS_UNARY" {} \;
/usr/include/boost/preprocessor/facilities/apply.hpp:24:#    define
BOOST_PP_APPLY_I(x) BOOST_PP_EXPR_IIF(BOOST_PP_IS_UNARY(x),
BOOST_PP_TUPLE_REM_1 x)
/usr/include/boost/typeof/template_encoding.hpp:61:
BOOST_PP_IS_UNARY(x),\
/usr/include/boost/spirit/utility/rule_parser.hpp:826:
BOOST_PP_EXPR_IIF(BOOST_PP_COMPL(BOOST_PP_IS_UNARY(elem)),elem)

In addition, Paul Mensonides mentioned the following in
http://lists.boost.org/Archives/boost/2004/08/70238.php
> Paul Mensonides wrote:
> I know. They (and other types of detection macros) are very useful. Right now,
> the Borland configuration is used by the IBM preprocessor and the Sun
> preprocessor also. I'd like to know whether or not those macro definitions work
> correctly on those preprocessors before I add it. Though those macros aren't
> part of the public interface, they are part of the internal interface. I.e.
> they are used internally as if they were a public interface (though they are
> used carefully on some preprocessors). They are stable, and the worst thing
> that might happen in the future is that they will be moved to a different
> directory. Thus, you can use them, but beware of VC and versions of MWCW prior
> to v9. They in particular have severe problems with expansion order. E.g. VC
> will even fail this test:

My Boost.Contract code internally uses BOOST_PP_IS_UNARY() and it
works fine on GCC 4.2.4 (Ubuntu Linux), MSVC 8.0 (Windows XP), and GCC
3.4.4 (Cygwin) but I have not tried other compilers (including
Borland's).

Thank you.
Lorenzo