Re: [boost] Review Request: Variadic Macro Data library

Subject: Re: [boost] Review Request: Variadic Macro Data library
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-18 21:58:01

On 2/18/2011 7:27 PM, Lorenzo Caminiti wrote:
> On Thu, Feb 17, 2011 at 5:13 PM, Edward Diener<eldiener_at_[hidden]>  wrote:
>> I am requesting that my library, the Variadic Macro Data library, which is
>> in the sandbox in the variadic_macro_data directory, be reviewed for
>> inclusion into Boost.
>>
>> The variadic_macro_data library adds support and functionality for variadic
>> macros to Boost as well as integrating variadic macros with the Boost PP
>> library without changing the latter library in any way.
>>
>> I believe others have used my library, can attest to its quality and that it
>> does what it is supposed to do. and have found it useful when using variadic
>> macros with Boost PP. I myself have used its functionality in my own TTI
>> library in the sandbox. Support for variadic macros is implemented in nearly
>> all modern C++ compilers and the syntax is natural for an end-user. The
>> library is finalized as far as functionality is concerned and I would like
>> to see it in Boost and am willing to maintain it as a Boost library.
>
> Is it possible to use variadic macros to detect empty parameters?

My understanding of variadic macro data is that at least one parameter 
must be specified.

>
> For example:
>
> #include<boost/variadic_macro_data/VariadicMacroData.hpp>  // Proposed lib.
>
> VMD_DATA_SIZE(1, 2) // 2
> VMD_DATA_SIZE(1)    // 1
> VMD_DATA_SIZE()     // 1 not 0 :((
>
> But I would like to the last size to expand to 0 (or have a different
> macro that would expand to 0 in that case).
>
> With a real C99 preprocessor (e.g., GCC) I can do the following
> because empty macro parameters are supported:

Are they for variadic macro data in C++ ?

>
> #include<boost/variadic_macro_data/VariadicMacroData.hpp>  // Proposed lib.
> #include<boost/preprocessor.hpp>
> #include<boost/preprocessor/facilities/is_empty.hpp>
>
> #define PP_VA_EAT(...) /* must expand to nothing */
>
> #define PP_VA_SIZE_1OR0_(x) BOOST_PP_IIF(BOOST_PP_IS_EMPTY(x), 0, 1)
>
> #define PP_VA_SIZE_(size, ...) \
>      BOOST_PP_IIF(BOOST_PP_EQUAL(size, 1), \
>          PP_VA_SIZE_1OR0_ \
>      , \
>          size PP_VA_EAT \
>      )(__VA_ARGS__)
>
> #define PP_VA_SIZE(...) PP_VA_SIZE_(VMD_DATA_SIZE(__VA_ARGS__), __VA_ARGS__)
>
> PP_VA_SIZE(1, 2)    // 2
> PP_VA_SIZE(1)       // 1
> PP_VA_SIZE()        // 0 :))
>
> But this does not compile on MSVC because while it supports variadics
> it does not support empty macro parameters :(

I will look at that and see what I can come up with. If variadic macros 
support an empty parameter list, I should provide a correct size of 0. 
If it does not I should indicate an error. So either way I will look to 
make a correction. Thanks for pointing this out.

>
> BTW, a few minor comments on you library:
> 1) I think a name like BOOST_PP_VA_... is better than BOOST_VMD. "VA"
> is the same abbreviation for variadics that C99 uses in __VA_ARGS__
> and Boost.Preprocessor already uses abbreviations like in
> BOOST_PP_SEQ.

What does the BOOST_PP_SEQ abbreviation have to do with BOOST_VMD_ ?

> Alternatively, I would consider BOOST_PP_VARIADICS_...
> but still not "VMD" because programmers will not know what VMD stands
> for.

I used VMD to represent (V)ariadic(M)acro(D)ata, which is really what my 
library is about and also integrating that data with Boost PP. I 
rejected VA because its connotation in C++ is "variable argument(s)" and 
my library is about manipulating variadic macro data. I feel that 
something like VARIADICS is too long but I would certainly agree to it 
if others found it more expressive. I also do not want it to be 
BOOST_PP_ anything unless others decide it should be part of Boost PP 
and not its own library, and in that case I feel Paul Mensonides would 
need to find that acceptable.

> 2) I would add PP_VA_EAT, PP_VA_IDENTITY, PP_VA_CAT (similar to what
> they do already in Boost.Preprocessor and they should be trivial to
> implement). Also, I would add `#define PP_VA_SAME(...) __VA_ARGS__`.

I am willing to add functionality to the library but I wonder where that 
would stop. Essentially variadic macro data is similar to any of the 
other data types in Boost PP in that it is really just a separate data 
type. Since the Boost PP data types already have a rich set of 
functionality I sort of feel that duplicating any of that functionality 
for variadic data itself will be redundant. This is especially true as 
my library has support for converting back and forth variadic data to 
any of the Boost PP data types. I feel pretty strongly that the use of 
variadic data with Boost PP should really be to provide a more pleasant 
syntax for the end-user, but once the programmer handles the variadic 
data he should convert it to a Boost PP data simply because that data 
type already has a rich set of functionality for dealing with the data.

I would be willing to add BOOST_VMD_CAT and BOOST_VMD_IDENTITY since 
they are both trivial ( just call to the appropiate BOOST_PP_ macros 
passing __VA_ARGS__ ). Your last is just __VA_ARGS__ as you show. But I 
really wonder if more functionality on variadic macro data is really 
worth it considering that the goal of the library, other than letting 
the end-user access individual tokens in the variadic macro data itself, 
is to convert back and forth to the Boost PP data types. I can 
understand that an end-user of the library such as yourself might want a 
number of additional operations on the variadic macro data itself, but I 
think if you look at the Boost PP data types you will see that their 
rich functionality offers most anything one would want to do with the 
data once you get it.