Re: [boost] library maintainer list

Subject: Re: [boost] library maintainer list
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-12-24 21:47:11

On 12/24/17 11:20 AM, Marc Glisse wrote:
> On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
>
>> On 12/24/17 10:30 AM, Marc Glisse wrote:
>>> On Sun, 24 Dec 2017, Robert Ramey via Boost wrote:
>>>> On 12/23/17 11:59 PM, Marc Glisse wrote:
>>>>>> (what about making this constexpr?).
>>>>> That's going to be hard, unless you are happy with making only 
>>>>> trivial things (construct, copy) constexpr
>>>> How come?
>>> How do you control the rounding mode at compile time?
>> Hmmm - I don't see anything special about rounding mode that would 
>> prevent it from being constexpr.
>
> The way this currently works is you call fesetround or some asm to set 
> the rounding mode of the FPU, then do your floating point operations 
> as usual, with various tricks to prevent broken compilers (at least 
> gcc and clang) from reordering arithmetic with rounding mode changes. 
OK - good explanation
> The only way I can think of to make operations constexpr (without 
> making them incredibly slow) is to detect if they are called in a 
> constexpr context, and in that case provide a software emulation. ]
I tried but so far haven't found a way to detect whether a function is 
being invoked at compile time or run time.  I have reason to believe 
that it's possible, but as I said, I haven't found it yet. It's also 
possible that the user invoke the functions with a different policy if 
he's using it in a context which he expects it to be invoked at compile 
time.  Actually, that would likely work in my case.
> Don't forget to use gcc's -frounding-math flag to see how much you 
> need to emulate...
And efficiency isn't really an issue at compile time.
>> The same sort of question could be raised about lots of aspects of 
>> this or any other library.  One can't really answer any of these 
>> questions until undertaking the task.  All or most of the functions 
>> depend solely upon their parameters and have not side effects.  But, 
>> in my recent experience, functions of this sort can generally be made 
>> to support constexpr.
>>
>> I'm sure there are functions for which supporting constexpr wouldn't 
>> be worth it.  Transdental functions come to mind.  But I don't think 
>> that everything would have to be constexpr in order to be useful.
>
> I think even addition or multiplication will not be so easy.
In my home brew version - which doesn't consider rounding error - these 
operations haven't caused any problems.  Unfortunately, the only way to 
really know is to try to do it.
> Or maybe you are interested in interval<int>? I was only ever 
> interested in interval<double>, but interval<int> should indeed be 
> easy to make constexpr.
That's what I've been working with right now.  Well, not quite, I'm 
using interval<checked_result<int>> which is sort an extended integer 
type.  But the interval code generic in that it's decoupled from the 
type.  The current versions are remarkably easy, hence my interest in 
seeing the official package support constexpr.

The considerations you mention above suggest that there would be a fair 
amount of extra information required to use the library effectively.  
That is, I think that the question of improved documentation would get 
promoted from desirable, to necessary.

-- 
Robert Ramey
www.rrsd.com
[phone]