Boost logo

Boost :

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.

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){
>     ? 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 ;
> 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:, nothing in develop yet.

However, should you wish to *experiment* in the mean time, then this is
available in develop of Boost.Math:

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at