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

Subject: Re: [boost] constexpr, cmath functions and other functions and distributions
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-07-28 11:44:19

2016-07-28 16:24 GMT+03:00 Paul A. Bristow <pbristow_at_[hidden]>:

> 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