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.
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.
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.
