-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Serguei KOLOS
That macro is 1) not a library interface (so why are you using it?)
I'm using it because I was looking for something to detect emptiness and have found a macro in the preprocessor library. I can tell you what makes me thinking that this is a public macro - it's name, which follows the same convention as all the other macros' names in the library.
and 2) is
not a general purpose emptiness detector (there is no such thing). There are very specific constraints on what the input is supposed to be. Now I understood that my impression was wrong.
I believe that I originally intended those to be client interfaces. I added them because someone wanted them, but I didn't document them (presumably because they aren't that useful or general). With variadics, about the best you can do is in this regard is placing a constraint on the input that requires the input not to end in a function-like macro name. Chaos (when variadics are enabled) has a IS_EMPTY_NON_FUNCTION macro which provides general purpose emptiness detection except for that input constraint. Without variadics (and placemarkers), the input has such severe constraints as to make any such macro non-general purpose. I.e. it is highly specific to the types of input that you need to use it with. For now, C++ doesn't have variadics and placemarkers, so I can't add the first one to the Boost Preprocessor library. The second is not general purpose enough to be added. I wish that I could add something like this, but without variadics and placemarkers, the result is always severely crippled. (Trust me, I've tried all sorts of ways to do this from all sorts of angles. It cannot be done without severely restricting input.) With variadics, the result is only slightly crippled (i.e. it is still generally usable).
May be it makes sense to have different prefix for private macros?
Hmm. In Chaos, I use the CHAOS_PP_ prefix for interface macros and the CHAOS_IP_ prefix for implementation macros. However, there are really three types of macros--client (external) interface macros, internal interface macros, and implementation macros. I use CHAOS_PP_ for both external and internal interfaces. In Boost, any given library is (by convention) given a namespace and a macro prefix. E.g. for some library xyz, you'd get boost::xyz and BOOST_XYZ_. The BOOST_PREPROCESSOR_ prefix was shortened to BOOST_PP_ (by consensus). So, what I'd have to do, without special dispensation to break the convention, is use a secondary prefix (such as BOOST_PP_IMPL_). Regards, Paul Mensonides