If we can get a consensus on support for GCC's libquadmath
in Boost.Multiprecision, I would volunteer to write the backend for it. But I need a few months before I get that kind of time slot for writing, testing, etc. I wonder what John and Paul think about adding support for this. I'm skeptical because the type really only works with one compiler, and then you need to --enable-quadmath when building GCC in order to get it. It's a nightmare!
I think this is really the issue - figuring out when to enable support for this feature.
BTW, I can see a genuine use case for constexpr 128-bit float constants even if the right way to handle __float128 is to wrap it in the Multiprecision lib. I wonder are there any predefined macros we can use like __SIZEOF_INT128__ is for __int128? John.
I agree, of course. It guarantees compile-time const-ness. In C++11, I use something like this: template<typename built_in_float_type> built_in_float_type const_pi() { // This is a true compile-time constant. return built_in_float_type(3.14159265358979323846264338327950288419716939937511); } I do not use any suffixes on the literal number. But you really need C++11 for this. And then you need to differentiate it from the multiprecision constants, which still might force the creation of template specializations. Quite honestly, I can never really sort it all out, but I suppose it's possible to do so. Has anyone suggested "long long double" for C++17? Sincerely, Chris.