Re: [boost] constexpr, cmath functions and other functions and distributions

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