Re: [boost] [config] consexpr workaround

Subject: Re: [boost] [config] consexpr workaround
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-11-16 16:44:12

----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 15, 2010 1:29 PM
Subject: Re: [boost] [config] consexpr workaround

> vicente.botet wrote:
>> "John Maddock" <boost.regex_at_[hidden]> wrote:
>>
>> >>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?
> 
> The purpose of constexpr is to mark something as a compile time constant such that it can be used in other compile time expressions, including types that weren't allowed as compile time constants before.  It allows for constant-expression functions, data, and even constructors.  Constant-expression data disallows dynamic initialization which const objects can undergo.  Without constexpr support, neither constant-expression functions nor constructors are supported, nor is floating point constant-expression data.  Thus, const is inappropriate in those cases, so BOOST_CONSTEXPR_OR_CONST cannot be used.

I think that we need to declare a constant variable as constexpr if we want it to be part of other constexpr. Am I wrong?

> For non-floating point constant-expression data, const could work fairly well, but it permits dynamic initialization, so for platforms supporting constexpr, code would fail to compile that mistakenly compiled on platforms without constexpr support.  

You are right. But it works well when the the data is staticaly initialized, which is the case for most of the constants.

> Thus, BOOST_CONSTEXPR_OR_CONST would lead to maintenance issues.  That means library code using BOOST_CONSTEXPR_OR_CONST and client code using that library code must either assume that BOOST_CONSTEXPR_OR_CONST merely means "const" or it must be conditionally compiled to account for either "const" or "constexpr."  In that case, BOOST_CONSTEXPR_OR_CONST does nothing to help.

If the client code must be portable also, it can assume only that the constant is "const". But for clients that use only c++, the constant must be declared constexpr, or not?
 
> I don't think BOOST_CONSTEXPR_OR_CONST is helpful.

Do you mean that a library that must provide a C++03 interface can not use constexpr on C++0x compilers as the meaning can change? In Boost.Ratio "num" and "den" are defined as const for C++03 compilers, and need to be constexpr for C++0x compilers. How do you write such a code in a "portable" way?

    ??? boost::intmax_t num = SIGN * ABS_N / GCD;
    ??? boost::intmax_t den = ABS_D / GCD;

For the moment I write it like that

    BOOST_RATIO_STATIC_CONSTEXPR boost::intmax_t num = SIGN * ABS_N / GCD;
    BOOST_RATIO_STATIC_CONSTEXPR boost::intmax_t den = ABS_D / GCD;

But maybe you prefer the following?

#ifdef BOOST_NO_CONSTEXPR
    const boost::intmax_t num = SIGN * ABS_N / GCD;
    const boost::intmax_t den = ABS_D / GCD;
#else
    constexpr boost::intmax_t num = SIGN * ABS_N / GCD;
    constexpr boost::intmax_t den = ABS_D / GCD;
#endif

Best,
Vicente