Re: [boost] problem with BOOST_PP_IS_EMPTY macro

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2006-02-22 05:57:25

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] 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