template specialization in C++03 as standard specify it.
This also works on GCC 4.6, 4.8.2 and 4.9 in C++11 and C++03, I needlessly
added this during some debugging where the compiler was telling me to do so.
I shouldn't have followed it's advice, as this breaks compatibility with
other compilers.
attribute_type and attribute_const_type when type is deduced can be
different than when the type is provided.
Indeed when specifying attribute_type and attribute_const_type manually
it's possible to provide a type which isn't const qualified as
attribute_const_type. When deducing the types from the get_expr, a const
and a non const qualified type is taken respectively for attribute_type
and attribute_const_type.
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 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)
...
)
