Boost logo

Boost :

Subject: Re: [boost] [config] consexpr workaround
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-11-13 08:20:14

----- Original Message -----
From: "John Maddock" <boost.regex_at_[hidden]>
To: <boost_at_[hidden]>
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)
> #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
>>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 .


Boost list run by bdawes at, gregod at, cpdaniel at, john at