On 2/18/2011 7:27 PM, Lorenzo Caminiti wrote:
On Thu, Feb 17, 2011 at 5:13 PM, Edward Diener<eldiener@tropicsoft.com> 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.