These macros are used to handle generation of boilerplate code or each
member to add to the adapted sequence. And in the commit
abff92ab65 we changed the signature of these
macros to handle generation of proxied object field type deduction, this
change simply fix the related macros.
As the BOOST_FUSION_ADAPT_STRUCT_FILLER* macros were changed to handle type
deduction, this breaks the usage that BOOST_FUSION_DEFINE_STRUCT makes from
them.
That is BOOST_FUSION_DEFINE_STRUCT_IMPL expects a simple tuple, while we
now provide a tuple containing the size of a nested tuple which either has
or not the type provided. But in the case of the DEFINE* macros it would be
a non-sense to support this kind of API as a field being defined cannot be
deduced. :)
As of BOOST_FUSION_ADAPT_STRUCT without type deduction, there were only
simple attributes filler. Now this need more complex logic to handle both
API: the backward compatible one with type specificiation, the one without
type specification and the non-variadic one which enables omitting the type
specification by providing BOOST_FUSION_ADAPT_AUTO instead of the type.
That's why I extracted the FILLER_* macros details in a separate source
file.
variadics arguments.
The following signature is possible :
BOOST_FUSION_ADAPT_STRUCT(
struct_name,
member_name0,
(BOOST_FUSION_ADAPT_AUTO, member_name1)
(member_type2, member_name2)
member_name3,
...
)
This enable the following flexible macro signature when there is
no BOOST_PP_VARIADICS support:
BOOST_FUSION_ADAPT_STRUCT(
struct_name,
(member_type0, member_name0)
(BOOST_FUSION_ADAPT_AUTO, member_name1)
(,member_name2)
...
)
If BOOST_PP_VARIADICS is active then there is quite more flexibility as it
allows to avoid the type specification:
BOOST_FUSION_ADAPT_STRUCT(
struct_name,
(member_type0, member_name0)
(BOOST_FUSION_ADAPT_AUTO, member_name1)
(,member_name2)
(member_name3)
...
)
