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