Fix ticket https://svn.boost.org/trac/boost/ticket/11157
BOOST_MPL_PP_TOKEN_EQUAL is now used to check if auto/BOOST_FUSION_ADAPT_AUTO
was provided as type, telling to deduce members types.
Note 1: Forwarding functions are specified as a C++14 constexpr since
std::forward is not a constexpr within C++11.
Note 2: Though I'm not sure why it doesn't compile, some declarations
are specified as a C++14 constexpr or non-constexpr.
Note 3: Boost.Tuple adaptation and TR1-based tuple implementations are
not constexpr.
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.
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,
...
)
