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

From: John Maddock (jz.maddock_at_[hidden])
Date: 2021-08-22 18:59:50

On 22/08/2021 19:14, Robert Ramey via Boost wrote:
> A couple of questions regarding the above new boost config macro.
>
> a) I note that this "breaks the pattern" of BOOST_NO_... which I was 
> expecting.  I've got no complaint about this, just like being 
> consistent when possible.

It's a "helper macro", we have BOOST_NO_CXX20_IS_CONSTANT_EVALUATED, but 
this is a strict C++20 only check.

For BOOST_IS_CONSTANT_EVALUATED/BOOST_IS_CONSTANT_EVALUATED_INT we have
BOOST_IS_CONSTANT_EVALUATED_VERSION with values 0,1,2 depending on 
whether we have no support, partial support, or full support.

>
> 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.  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.
>
> c) In my Jamfiles I generally have a few tests which run conditionally 
> on the config macro values like this:
>
> test-bsl-run_files test_array : A : :Â  requires cxx11_hdr_array ; 
> #BOOST_NO_CXX11_HDR_ARRAY
>
> What should I use with the above macro?  Particularly confusing is the 
> usage of _NO_ in the macro and the exclusion of _no_ in the requires 
> variable.  Should it be something like this.
>
> test test_is_constant_evaluted : A : :Â  requires 
> cxx20_no_is_constant_evaluated_int ; #BOOST_IS_CONSTANT_EVALUATED_INT
Good question, the feature would definitely work with [ requires 
cxx20_is_constant_evaluated ], note the spelling, but that would 
restrict tests to true C++20 ones.
>
> d) Looks like part of this already checked into config.hpp on the 
> develop branch.  I would like to add something to my current develop 
> to permit me to start using this now until you get the final code 
> checked in.  Any suggestions about the easiest way to do this?  I'm ok 
> with inserting some code temporarily but would prefer not to have to 
> sprinkle it all over the place.

It's a PR awaiting comment at present: 
https://github.com/boostorg/config/pull/394, nothing in develop yet.

However, should you wish to *experiment* in the mean time, then this is 
available in develop of Boost.Math: 
https://github.com/boostorg/math/blob/develop/include/boost/math/tools/is_constant_evaluated.hpp.

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.

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?

Best, John.

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus