Indeed when some parameter are BOOST_PP_EMPTY the last parameter is
accessed correctly but results in a compilation error which doesn't stop
some compiler (e.g. g++) to go through the preprocessing pass and still
compile the binary correctly. But to avoid the error message I used a
workaround which behaves better. I preferred factoring it out to make
clear that there are some reason why this element is strangely accessed.
This feature is enabled when BOOST_PP_VARIADICS also is, as it rely on it.
A placeholder for the type can be used when BOOST_PP_VARIADICS isn't
active.
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 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)
...
)
