...

Is there any support for making std::abs and friends constexpr where>> possible in future versions of the C++ Standard?

Here are the bad news: C++ committee wishes to keep it possible for the implementors of the Standard Library to reuse C headers. Well, I was also thinking along these lines. I am not sure if the C++language requires constexpr versions of any mathematical functionsor if this is left as an implementation-specific artifact, or evenif it is specified as non-constexpr for C compatibility. In othercommunications, it has been mentioned that GCC providessome constexpr built-ins for certain <cmath> functions.But this might be an implementation-specific design choice,not a specification fulfillment. There is a small chance that a paper on making some of the C math> functions constexpr may be accepted if functions are trivial to> implement efficiently. Basic functions such as absoulute value, sign manipulationas well as elementary transcendental functions such as trigonometricfunctions and power functions could readily be implemented asconstexpr. In my opinion, it depends on the direction of the C++language if these should actually be required in a constexpr form.

There is also a technical detal. Another Boost author reminded that C++ can't overload on constexpr-ness. So there might bedifficulties with naming conventions for constexpr math functions. Questions might arise like: Do you want sqrt(x) and alsoconstexpr_sqrt(x)? Do you need a <cmath> constexpr namespace? Best regards, Chris On Thursday, July 28, 2016 5:44 PM, Antony Polukhin wrote: 2016-07-28 16:24 GMT+03:00 Paul A. Bristow :

After much head scratching (and some head banging) - against a string of "Computer Says No" inscrutable diagnostic messages.

It often helps to debug the constexpr realted issue using Clang compiler. Sometimes it may provide more diagnostics than GCC (but sometimes it compiles code that GCC refuses).

I believe that I have now produced a (partial) version of Boost.Math normal_distribution that can be a constexpr using GCC6.1.1.

That's very very very good. However see the bad news down below.

Without most cmath functions it seems to me impossible to write any reasonable (so-called special or not) mathy function or statistical

distribution that can be constexpr.

<...>

Is there any support for making std::abs and friends constexpr where possible in future versions of the C++ Standard?

Here are the bad news: C++ committee wishes to keep it possible for the implementors of the Standard Library to reuse C headers. I've tried to add constexpr to the <cstring> in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r0.html The committee sad 'No', so I've removed the changes to <cstring> and only then the paper passed into C++Next. There is a small chance that a paper on making some of the C math functions constexpr may be accepted if functions are trivial to implement efficiently. I can write such paper and represent in to the C++ committee, but I'll need a lot of help with: * writing a list of C functions that could be simply implemented from scratch without affecting performance (functions that usually take 1-3 lines to implement). * implementing each of those function using constexpr At least users will have the constexpr implementation in Boost.Math if the paper won't be accepted. -- Best regards, Antony Polukhin _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 29 July 2016 14:07 To: Boost Developers List Subject: Re: [boost] constexpr, cmath functions and other functions and distributions

On Thu, Jul 28, 2016 at 11:44 AM, Antony Polukhin wrote:

...

2016-07-28 16:24 GMT+03:00 Paul A. Bristow :

...

Is there any support for making std::abs and friends constexpr where possible in future versions of the C++ Standard?

Here are the bad news: C++ committee wishes to keep it possible for the implementors of the Standard Library to reuse C headers. I've tried to add constexpr to the <cstring> in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r0.html The committee sad 'No', so I've removed the changes to <cstring> and only then the paper passed into C++Next.

There is a small chance that a paper on making some of the C math functions constexpr may be accepted if functions are trivial to implement efficiently.

The chance of that happening is much increased if there are National Body comments to the C++17 ballot requesting constexpr C math functions.

So Paul should file a comment with the BSI (Roger Orr, IIRC), and anyone else who cares should file a comment with their National Body.

I have made some remarks on this already (though there were some dark mutterings about undefined behaviour).

...

I can write such paper and represent in to the C++ committee, but I'll need a lot of help with: * writing a list of C functions that could be simply implemented from scratch without affecting performance (functions that usually take 1-3 lines to implement). * implementing each of those function using constexpr

Having such a paper also would increase the chance that the C++ committee will act.

...

At least users will have the constexpr implementation in Boost.Math if the paper won't be accepted.

Again, the fact that Boost.Math has implemented such constexpr functions increases the chance that the committee will add them to the standard.

I don't want to overplay this - I've only done one function of one distribution as a 'proof of concept'. It was tiresome and the prospect of doing all the functions and all the distributions is daunting. And making of code that will work for constexpr-savvy and older compilers that are not isn't appealing either. I also ran into the sand trying to do the erf function (needed for normal CDF). Ironically it was in the complexity of extra code ensuring that the order of initialisation is correct, one of the potentially important features of constexpr, if I understand correctly. I also worry about creating three sets of cmath functions, some constexpr and some not yet, and others that are impossible like frexp because they 'return' by assigning via a pointer. This is going to be confusing? GCC seems well on the way with its so-called __builtin_* versions. https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html I am also sensitive to the feeling that this is not a top priority for C++ standardization compared to other new features, not just in constexpr. But making cmath functions constexpr surely should be a long-term ambition, especially for embedded IOT and phones. HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830