
----- Original Message ----- From: "John Maddock" <boost.regex@virgin.net> To: <boost@lists.boost.org> Sent: Saturday, November 13, 2010 10:40 AM Subject: Re: [boost] [config] consexpr workaround
in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not.
#if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif
OK
I will provide a patch with doc and tests.
We could also add a STATIC_CONSTEXPR macro
#define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST
For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used.
I don't see how that can work:
* If the type being initialized is known to be an integer type then we can use BOOST_STATIC_CONSTANT and we wouldn't gain anything from using constexp?
I think I'm missing something. Do you mean that we don't need to use constexpr for the variable value? template<typename _Tp, _Tp __v> struct integral_constant { static constexpr _Tp value = __v; typedef _Tp value_type; typedef integral_constant<_Tp, __v> type; constexpr operator value_type() { return value; } }; Why then the C++0x proposal includes it?
* If the type being initialized might not be an integer type, then we can use constexp or a static const declaration, but we can't use BOOST_STATIC_CONSTANT (because it may be implemented in terms of an enum).
Right, in this case nothing can be done . Best, Vicente