Re: [boost] [preprocessor] Variadics suggestion

Subject: Re: [boost] [preprocessor] Variadics suggestion
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-09-25 21:40:54

On 09/24/2012 04:15 PM, Kitten, Nicholas wrote:
> Hi Folks,
>
> First of all, I'd like to say "thank you" to Edward Diener and Paul
> Mensonides for incorporating variadics support into
> Boost.Preprocessor, which has been on my wishlist for a long time.

Thanks !

>
> In fact, I wanted it badly enough that I've been using my own slightly
> modified version of the library assuming variadics for a while now,
> and I was interested to see what a cross-platform version would look
> like (mine was only tested on MSVC).  I think the chosen approach of
> converting variadics to non-variadics is probably superior to the
> breaking algorithm changes I made in my own version, and I would
> humbly suggest a few more additions in the same spirit.
>
> The reason I chose to use variadics in the first place was to simplify
> the user interface for the common case of manipulating what I'll call
> a "variadic sequence," (a series of concatenated tuples), which I
> wanted to look similar to the following:
>
> #define FILTER_PARAMETERS  (A, int, 3)\
>                                                      (B, float, 2.0f)\
>                                                      (C, const char*, "Howdy!")
>
> Of course, without variadics you need either a set of macros for each
> tuple size, or else double parenthesis around each tuple, which
> becomes even more burdensome when users are also required to
> parenthesize inner arguments, leading to gems like this one:
>
> #define FILTER_PARAMETERS ((A, (TypeConverter<double, float>),
> (TypeConverter<double,float>()))
>
> My solution admitting the preferred format was to replace most private
> SEQ_*(X) macros with SEQ_*(...), which also required modifying
> SEQ_ELEM() and SEQ_HEAD() to return (X) instead of X.  However, it
> occurs to me now that a conversion function to go from variadic to
> regular sequences would've been easier to implement and backwards
> compatible; see the attached file, which I've tested in basic cases on
> MSVC 10 and gcc-4.3.4.  The usage would be:
>
> #define SEQ    (a,b,c)(1,2,3,4)
> BOOST_PP_VARIADIC_SEQ_TO_SEQ( SEQ )    // expands to ((a,b,c))((1,2,3,4))
>
> I'm submitting this because I couldn't find a way to use some
> combination of TUPLE/VARIADICS and SEQ transformations to do the same
> thing succinctly, but if I'm just missing something, please let me
> know.
>
> Next, I would suggest having a documented IS_EMPTY(...) function for
> detecting an empty variadic list.  Since is_empty.hpp already exists
> for single arguments (though undocumented), I would guess the variadic
> version would look quite similar.  My own (MSVC) version is attached.

Please see my Variadic Macro Library in the sandbox for some further 
programming efforts with variadic macros. The IS_EMPTY(...) there is 
largely taken from one of Paul's posts on the Internet.

As Paul has pointed out many times no completely perfect implementation 
of IS_EMPTY(...) is possible,

In my VMD library I attempted some clever preprocessor programming with 
variadic macros even knowing that while IS_EMPTY(...) is always flawed, 
an understanding of how and when it is flawed might allow some ideas to 
work if one avoids the flawed situations.

Also dealing with VC++ is a real PITA but I attempted my best to work 
around the VC++ preprocessor. However I would not wish the VC++ 
preprocessor on anyone who needs to do serious preprocessor programming. 
It really is too bad that MS has taken the road of supporting an 
essentially broken implementation because it works most of the time if 
one does fairly simply things with it, even while they know it is broken 
according to the C/C++ standard.