C++ Logo


Advanced search

Re: [wg14/wg21 liaison] [isocpp-ext] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)

From: Jorg Brown <jorg.brown_at_[hidden]>
Date: Sun, 19 Sep 2021 17:19:18 -0700
On Fri, Sep 17, 2021 at 2:27 PM Joseph Myers <joseph_at_[hidden]>

> On Fri, 17 Sep 2021, Jorg Brown via Liaison wrote:
> > Re: "strfromf128", is that documented anywhere? N1312 doesn't mention it
> > and Google is surprisingly unhelpful... I presume it's just
> > https://man7.org/linux/man-pages/man3/strfromd.3.html but with added
> types?
> You should be using
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf as the current
> C23 working draft, which documents strfromd, strfromf and strfroml (and
> corresponding strfromd32, strfromd64, strfromd128).

Thanks Joseph, that's really helpful.

 On Fri, Sep 17, 2021 at 4:05 PM David Olsen <dolsen_at_[hidden]> wrote:

> Jorg Brown wrote:
> >> That's problematic, depending on the overload-resolution rules for the
> new floating-point types.
> >> [… example with int*N*_t types …]
> In the early days of P1467 there was a vigorous debate about whether the
> std::floatN_t types could be typedefs of standard types or not. People
> pointed out the problems that the interactions between the int*N*_t types
> and overloading, and that argument won the day. The std::float*N*_t
> types must be different types than float, double, or long double, similar
> to how the _Float*N* types are different type than float, double, or long
> double in C. It will be possible to have overloads of both float and
> std::float32_t. The exact details of overload resolution in P1467 are
> still being worked out, but overload sets on floating-point types will not
> run into the same problems that overload sets on integral types currently
> do.

That's great to hear!

> >> for my purposes I'd want something that corresponded to std::float16,
> not necessarily _Float16.
> std::float16_t in C++ and _Float16 in C are required to have the same
> representation and same sets of values. If your implementation defines the
> FLT16_* macros in <float.h>, then you can use them for std::float16_t. Or
> you could get the information via std::numeric_limits<std::float16_t>.
> P1467 does not require that C++ implementations define the FLT16_* macros.
> Those macros will eventually make their way to C++ when the C++ standard
> library rebases on top of C23.

Speaking of numeric_limits...

If the C types and the C++ types are different, I'm concerned that
std::numeric_limits<_Float16> might not work when
std::numeric_limits<std::float16_t> will. (I'm already sometimes running
into that problem with __int128. And yes, I know __int128 isn't covered by
the standard and hence I shouldn't expect it to work...)

-- Jorg


Received on 2021-09-19 19:19:32