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 discussed with Agustín Bergé and Joel de Guzman on https://github.com/boostorg/fusion/pull/3,
it's better to remove the separate macro for the type deducting macros, and
to instead support a flexible API allowing backward compatibility and type
omission.
This is what ADAPT_STRUCT and ADAPT_STRUCT_TPL now provides. All other
macros will be improved in the same way in the following commits.
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)
...
)
