> On 30 Dec 2024, at 16:11, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > >> On Mon, 30 Dec 2024, 14:28 Hans Åberg, <haberg_1@xxxxxxxxxx> wrote: >> >>> On 30 Dec 2024, at 14:24, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >>> >>> On Sun, 29 Dec 2024 at 14:57, Hans Åberg <haberg_1@xxxxxxxxxx> wrote: >>>> >>>> >>>>> On 29 Dec 2024, at 15:16, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >>>>> >>>>> On Sun, 29 Dec 2024 at 10:01, Hans Åberg via Gcc-help >>>>> <gcc-help@xxxxxxxxxxx> wrote: >>>>>> >>>>>> When checking the GCC 14.2 implementation of C++23 fixed width floating-point types in the header <stdfloat> [1]: >>>>>> >>>>>> The page [2] says that one should be able to write std::float128_t using std::formatter as it is using std::to_chars which is required to support all arithmetic type, but it does not work with GCC. >>>>> >>>>> It works fine for me. >>>>> >>>>>> But the wording suggests it has been working with GCC. >>>>> >>>>> And still is working. >>>>> >>>>> If it's not working for you, it must be a limitation of your OS, which >>>>> you haven't told us. >>>> >>>> It is MacOS 15.2, Silicon, but I think the error is the same on Intel, with >>>> % g++ --version >>>> g++ (MacPorts gcc14 14.2.0_3+stdlib_flag) 14.2.0 >>> >>> That's the problem then. std::to_chars is only defined for float128 >>> under these conditions: >>> >>> #if defined(__STDCPP_FLOAT128_T__) && >>> defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128) >>> ... >>> #elif defined(__STDCPP_FLOAT128_T__) && defined(_GLIBCXX_HAVE_FLOAT128_MATH) >>> ... >>> #endif >>> >>> The HAVE_FLOAT128_MATH macro is currently only defined for Glibc 2.26 >>> and later, on targets that support __float128. The C++ features are not implemented for some reason, as one can use the GNU <quadmath.h> library and adding to g++ the library option -lquadmath, as in this example: https://stackoverflow.com/questions/5451447/quadruple-precision-in-c-gcc >> Maybe it would make the errors clearer if we did this: >> >> --- a/libstdc++-v3/include/std/charconv >> +++ b/libstdc++-v3/include/std/charconv >> @@ -913,6 +913,11 @@ namespace __detail >> to_chars_result to_chars(char* __first, char* __last, _Float128 __value, >> chars_format __fmt, int __precision) noexcept; >> #endif >> +#else >> + // No libc support for formatting 128-bit floating-point types. >> + to_chars_result to_chars(char*, char*, _Float128) = delete; >> + to_chars_result to_chars(char*, char*, _Float128, chars_format) = delete; >> + to_chars_result to_chars(char*, char*, _Float128, chars_format, >> int) = delete; >> #endif > >> Even though it might help readability of diagnostics, the use of the keyword “delete” might destroy the implementation of hacks, as the meaning is to prohibit what is semantically wrong, not what is currently missing and might be added later on. >> >> There ought to be a keyword “unimplemented” that allows user implementation on top of it. >> > If users want to provide their own implementation they should do so in a different namespace. That is for user features. For unimplemented standard library features, one would like to be able to make a hack in such a way that when the feature becomes available, the code does not have to be rewritten except for, at some suitable point in time, removing the hack. On large projects, the one who wrote the hack may not be available, so it would suffice with some straightforward cleanup.
