From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-08-04 19:03:39
On 8/4/21 9:26 PM, John Maddock via Boost wrote:
> On 04/08/2021 19:05, Robert Ramey via Boost wrote:
>> On 8/3/21 4:29 PM, Robert Ramey via Boost wrote:
>>> Any chance of seeing a feature macro for HAS_IS_CONSTANT_EVALUATED
>>> appearing in Boost.Config any time soon?
>>
>> I guess it's not really necessary as std::is_constant_evaluated is
>> slated for C++20. And it includes a corresponding feature macro so it
>> shouldn't be necessary for boost.config to include this functionality.
>> I might have preferred the "unified" model of using boost.config for
>> all these but I guess the easiest is just to role with the times.
>
> Actually there is a roll for Boost.Config here:
> std::is_constant_evaluated is valid in C++20 mode only, as is it's
> feature detection macro. However, the underlying compiler intrinsic
> works just fine all the way back to C++11 mode as long as the compiler
> has implemented it.
>
> Multiprecision has the logic for this already:
> https://github.com/boostorg/multiprecision/blob/dd4d566055ff6eee6006f8f954efd3035bdf442a/include/boost/multiprecision/detail/number_base.hpp#L96-L132
> albeit somewhat complexified because it uses __builtin_constant_p to
> approximate std::is_constant_evaluated on older gcc versions.
I might add that including <type_traits> just to test got a feature
macro is not good.
I think, a better solution would be a header that defines
boost::is_constant_evaluated() and a BOOST_NO_IS_CONSTANT_EVALUATED
macro if it is not supported and always returns false. We already have
tools like this in Boost.Core.