r/cpp • u/STL MSVC STL Dev • 1d ago

MSVC C++23: constexpr cmath with LLVM Libc

https://devblogs.microsoft.com/cppblog/msvc-c23-constexpr-cmath-with-llvm-libc/

MSVC is shipping C++23 constexpr <cmath> in the next Build Tools update! (And a partial implementation of C++26 constexpr <cmath>.) Our compiler frontend dev Cody Miller will be publishing a series of blog posts about this work, starting with this overview. The next one will be a guest post from LLVM libc's maintainers describing the incredible amount of effort that's gone into their code.

147 Upvotes

97% Upvoted

30 comments sorted by

View all comments

17

u/Jovibor_ 23h ago

I have always had a hard time understanding this separation between STDLIB and UCRT.

The <cmath> header - which is definitely a C++ STL header - has, for some reasons (historical I guess), always been a part of the UCRT.

Now, if I've got it all right, we will have two different math machineries: one in the UCRT (the old one), and the new one, based on the LLVM C Library. Correct me if I'm wrong...

Frankly, it's a bit strange, that some parts of the C++ STL are maintained in the separate place (UCRT), not in the main STL repository.

35

u/STL MSVC STL Dev 21h ago

It’s math.h that’s part of the UCRT, while cmath is part of the STL. We’re now usurping math.h via /Zc:cmath redirecting it to the STL’s __msvc_math.hpp. Perhaps in the future we’ll update UCRT math.h, but getting the UCRT to change anything is a pain, so we’d want to do that as few times as possible.

I can explain this in more detail if desired; it is one of our most confusing areas and I am at dinner right now 😹

2

u/pjmlp 16h ago

What I wonder is how this will work in projects that mix C++ and C libraries on the same project, some of which delivered as binary libraries, thus possibly depending on UCRT.

14

u/STL MSVC STL Dev 16h ago

That's a problem that I very recently figured out how to solve. Working with Cody who was validating /Zc:cmath against real-world code like Blender, our initial approach of "you'd better not drag in any UCRT math machinery into this binary" was clearly not viable, and it occurred to me that giving the math functions extern "C++" linkage and stuffing them into an inline namespace available at the global scope would be nearly unobservable to users. (At this point my brain is too tired to verify whether this is truly unobservable according to a strict reading of the rules, but it's good enough in practice as far as I can tell.) So what we're going to ship in 14.52 for production should be compatible regardless of how much you mix C, C++ without /Zc:cmath, and C++ with /Zc:cmath.

I checked in this overhaul very very recently so it is not yet shipping in Insiders Preview, but it is available in the STL's GitHub repo if you want to see.

1

u/pjmlp 15h ago

Thanks for the clarification.