Subject: Re: [boost] library maintainer list
From: Marc Glisse (marc.glisse_at_[hidden])
Date: 2017-12-24 19:20:00
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. 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. Don't forget to use gcc's
-frounding-math flag to see how much you need to emulate...
> 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.
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
-- Marc Glisse