-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: Monday, February 25, 2013 6:26 PM To: boost@lists.boost.org Subject: Re: [boost] [math] Support for libquadmath/ __float128
So this means that the suffixes L and l are the "longest"
floating-point suffixes supported by the language and that the suffixes Q and q are non-portable language extensions. Is this right?
Correct.
So the only way to add Q or q suffixes would be to find a way to query the environment if it is supported. I wonder if GCC with --enable-libquadmath has a kind of query for this.
I haven't found one - gcc-4.7.2 has all sorts of __SIZEOF_XXX__ defines for every last type *except* __float128 and __float80 :-(
It won't help now, but is 'more precise types' an issue to raise with WG21 for the next C++ standard? Or is Multiprecision the way to go? Paul
I would welcome both.
Remember what a relief it was to finally be able to use specified fixed-size integers such as std::uint16_t, std::uint32_t, and the like? These standardized types solved a host of portability problems for integer algorithms.
Having fixed-precision floating-point types such as std::float32_t, std::float64_t, std::float128_t would, in my opinion, solve an even grander host of portability issues for floating-point algorithms. We have all grudgingly struggled with these for 30 years.
(Where has my long lost love Fortran77's REAL*16 from the '80s gone?)
Although multiprecision can, and possibly should, be addresses, I would not rely on multiprecision alone for a potential std::float128_t. The reason for this is because a potential std::float128_t can be well- implemented *on-the-metal* on many systems and offer the high performance thereof. Multiprecision will always suffer large performance losses (unless it gets onto a GPU).
Agreed. So what do we need to get into the next C++ version in order to facilitate this? Does std::decimal_128 in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1977.html give any good ideas? 1 std::float32_t, std::float64_t, std::float80_t, std::float128_t, and std::float256_t (and even std::float512_t - though I would think that 512 was time to go multiprecision) 2 A mechanism to discover which of these are supported by a particular implementation. (Testing if sizeof double == sizeof long double is a crummy way to find out if long double is really supported! We need something better - and I'd prefer a language solution rather than a macro). 3 Suffix(es) like Q to define longer constants? It takes a (much too) long time to get these things into the Standard and even longer to get them implemented, so we need to plan a long time ahead. Views? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com