u/__Mark___

It's harder than you think ;-) /u/STL calls it C++17's final boss (https://youtu.be/2m635u98CK0) One of the nice features of to_chars that it can print the shortest round-trip value. This value may require a lot of digits DBL_MIN has 715 significant digits (https://www.exploringbinary.com/maximum-number-of-decimal-digits-in-binary-floating-point-numbers/). There are some algorithms/libraries, but you need to write proper tests for edge cases that takes quite a bit of time.

To make things more interesting, for libc++ we have at least 4 different long double types. 64-bit on Windows (basically a normal double), 80-bit Intel, 128-bit IEEE-754, and double double on IBM platforms. The latter 3 all need new test cases. Most existing libraries only have support for float and double, this means adapting these libraries for our long double types needs quite a bit of investigation of how to convert these types and then adapting the exiting libraries.

For to_chars /u/STL offered MSVC STL's implementation and for from_chars we worked with LLVM libc to reuse their code. Both do not have long double support for all our platforms.

We're still working on C++17, but the things remaining are the hard parts; integrate the parallelism TS, special math function, and string conversion. Some work has been done. For example, from_chars for floating-point has been implemented this release; except for long double.

Thanks for the great summary of the last meeting!

In the section "Main C++26 Features approved in Hagenberg"

• P3471R3: Standard Library Hardening -> In the plenary we voted on R4
• P3070R2: Formatting enums -> We didn't vote on this paper in plenary

(edit formatting)

This is not true. I've been working on LLVM (mainly libc++) for several years as volunteer. I've never heard or observed PRs being rejected because the author was not in the industry. Often, when reviewing code, I don't know whether or not somebody is hobbyist. Getting code reviewed can sometimes be difficult; there seem to be more patches written than there is review bandwidth.

https://llvm.org/docs/GettingInvolved.html has a lot of information how to participate and join the LLVM community.

I know and I understand. The patch is still on my todo list. Finding a large block of uninterrupted time for a complex review is challenging.

std::from_chars for floating-point types disagree the special math functions are the last missing part ;-) Both of them are quite a bit of work and don't seem to attract a lot of people willing to work on them.

We have indeed have less resource than I would like. Getting review help by domain experts is most definitely welcome. For the Boost.Math patch there are concerns the license may not be compatible with libc++'s license.

As others have mentioned the LLVM project moved from Phabricator to GitHub. There are several mentions of how to reach us, the best way is to join Discord. There is a #libcxx channel where you can talk to us.

I hope to see you on Discord!

Please keep in mind that modules in libc++ are still experimental and that the usage experience is not mature yet. We're still working on improving the experience.

I know the clang developers have discussed whether the `std` module should work without build system support. I don't know the outcome of that discussion.

If your apt packages are build with module installation enabled you can use them. There is no CMake support for that, but you can adapt this script for your own purposes.If they are not build with module installation you indeed have to go with the self build route.

The difference in not between clang-17 and C++23 modules. The difference is between clang modules and the standardized modules in C++20. (It does not help their naming is quite similar and when people talk about modules it's not always clear which of the two they main.) The module map belongs to Clang modules; which indeed uses the unfortunate name `std`.

Modules have a lot of advantages I would suggest to look at talks on youtube of some of the well known C++ conferences. They will also teach you a lot about how to use modules.

`-fmodules` uses Clang modules https://clang.llvm.org/docs/Modules.html. This predates the C++20 modules and is more like header units.

For C++20 modules you need to omit the `-fmodules` flag and follow these instructions https://libcxx.llvm.org/Modules.html#using-in-external-projects. This requires you to build libc++ yourself. This supports both the `std` and `std.compat` module. I've had reports form people are successfully using this approach.

I'm aware this is not a great way to use modules. However libc++'s now at a point where build systems can start working on support for modules. I know CMake is working on adding support for `import std;`.

CMake has module support since 3.26, starting with 3.28 it's considered no longer experimental. However it does not support using libc++'s installed module sources; I added this to libc++ long after CMake 3.28 was released. This is the support the CMake developers looking into.

Thanks for the post and nice to hear you're using it in production. A few additional notes. * Whether this is available depends on whether your vendor enables the experimental feature. * There is no build system support for this yet. I know CMake is looking at it and I strongly expect build2 is also working on it. * The information in https://libcxx.llvm.org/Modules.html is based on a self-build libc++, this has been available since LLVM 17.

Standard Library Module support for C++20 in libc++ will be in LLVM-18. LLVM-18 is scheduled for release next month. The support in libc++ is still considered experimental.

The libc++ part of the script looks very familiar ;-)

Thanks! I think that sums up the status of STL development quite nicely. I strongly agree with the "number of skilled C++ developers with enough time on their hands". There are few people working on Standard library implementations and some of us can only contribute in their spare time.

Thanks to u/STL libc++ has a to_char floating-point implementation at all.

The big 3 agreed to make the std and std.compat module available in C++20. Both MSVC STL and libc++ have implemented this change.

I expect libc++ 18 will be able to install its experimental modules. But that is still work in progress. SG15, the tooling workgroup, is working on solving the toolchain questions.

I, the author of libc++'s std::format implementation, agree the error messages are not great. This has been one of my large gripes with std::format. Recently, I started experimenting with a non-Standard library and with the use of https://wg21.link/P2741R3 "User-generated static_assert messages" I managed to get better error messages. For example, ctf::format<"{1}">(42); could give a message like In file included from …/test/diagnostics.cpp:12: …/include/ctf/format.hpp:553:19: error: static assertion failed due to requirement '!"parse error"': requested argument 2 while 1 argument is available {1} ~

553 |     static_assert(!"parse error", token_list);
       |                   ^~~~~~~~~~~~~~
 …/test/diagnostics.cpp:65:14: note: in instantiation of function template specialization 'ctf::format<fixed_string<4UL>{"{1}"}, int>' requested here
  65 |   (void)ctf::format<"{1}">(42);
       |              ^

This code is only available on my system; I will try to upload the working parts this weekend.

I don't disagree. However I'm not the author of the paper.

Originally there was one paper P2905R0. This got split in P2905R1 and P2918R1. See the poll.

The current char to wchar_t conversion in std::format does not take any encoding into account. So when the char is a UTF-8 code unit then the conversion to wchar_t may not work correctly. If you know what your data contains, a simple cast from char to wchar_t might suffice. But that does not work in the general case.

They should not be combined. Most likely you want to use P2728R5 "Unicode in the Library, Part 1: UTF Transcoding"

At the moment no, but there is a discussion how to improve it. u/Daniela-E her C++ on Sea talk linked in that thread has some numbers. I haven't seen that talk so I don't know what she exactly measured.

Depends on how badly you want it ;-) With the development version of Clang + libc++ you can use modules, but it's not a great user experience. I'm working on std::print, which I hope to get done before the next release.

Modules will not be in a better shape in the next release. (Source: I'm working on both these features in libc++.)

I've not tested with Clang 16, but only with Clang trunk but modules and CMake 3.26 work. However there are still major bugs and a lot of limitations in Clang's implementation, see https://github.com/llvm/llvm-project/issues?q=is%3Aissue+is%3Aopen+label%3Aclang%3Amodules. There are several people actively working on this area of Clang and things keep improving.

I've not tested libc++ with header units, they may or may not work. There is no support for the C++23 std(.compat) modules yet. However we're working on that feature. This post https://discourse.llvm.org/t/rfc-about-the-default-location-for-std-modules/69191/29 has some information and it links to my patch in Phabricator. (No code has landed in LLVM repository yet.)

No we made changes in Clang and libc++ making the experimental library easier to use. This requires Clang 15 and your vendor should ship the experimental library. (I expect most of the vendors do so be default.)

Then it's one extra switch to enable the experimental library -fexperimental-library

https://godbolt.org/z/5xdc4Ke99

It's in there ;-) https://releases.llvm.org/15.0.0/projects/libcxx/docs/ReleaseNotes.html

The C++20 format library is feature complete, but not all Standard LWG issues have been addressed. Since it is expected that at least one of these issues will cause an ABI break the format`The C++20 format library is feature complete, but not all Standard LWGissues have been addressed. Since it is expected that at least one of these issues will cause an ABI break the format library is considered experimental.

I'm not sure how far behind Apple Clang exactly is but the current version of Apple Clang supports concepts. The version numbering of Apple Clang and Clang aren't related, which can be confusing.

Thanks for the gold stranger.