Re: BOOST_IS_CONSTANT_EVALUATED_INT(integer-expression)(integer-expression)

From: Robert Ramey (ramey_at_[hidden])
Date: 2021-08-22 20:27:24

On 8/22/21 11:59 AM, John Maddock via Boost wrote:
 >
 > b) My intended usage is something like:
 >
 > template<typename T>
 > constexpr interval<T> get_interval(const T & t){
 >     return BOOST_IS_CONSTANT_EVALUATED_INT(t)
 >     ? interval<T>(t, t)
 >     : interval<T>(
 >     std::numeric_limits<T>::min(),
 >     std::numeric_limits<T>::max()
 >     );
 > }
 >
 > is this the intended way to use this?  If not, what would be the 
correct usage.

Yes.... but the function should really return the same value in both 
constexpr and runtime usage.

LOL - for me, the whole point of this is to use a different value 
depending on whether or not the value is known at compile time. Maybe 
someone wants to opine on this.

This is especially true for BOOST_IS_CONSTANT_EVALUATED_INT which may 
evaluate to true simply because optimizations are on and the compiler 
has decided that the argument is known at compile time.  This has caused 
some discussion on the PR to the effect that possibly 
BOOST_IS_CONSTANT_EVALUATED_INT should not be provided.
> 
> I note that this has BOOST_MATH_NO_CONSTEXPR_DETECTION which might be 
> the right kind of macro to transplant to Boost.Config rather than
> BOOST_IS_CONSTANT_EVALUATED_VERSION.

With the current design - not strictly dependent upon 
is_constant_evaluated() - that would seem less confusing to me.

> So.... a design question for everyone: is porting constexpr-detection to 
> older gcc versions that have __builtin_constant_p worth the hassle of a 
> slightly changed interface and possibly also semantics?
> 

I don't have a strong opinion.  Somehow I'm thinking that at most one 
other person will have an opinion on this.

Robert Ramey