Re: [boost] [config] consexpr workaround

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)
> #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