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