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_co.... 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