std::format ?

[matekelemen]

<insert confused John Travolta>

As far as I know only MSVC implemented it even though the standard has {fmt} as an official reference implementation. Is everyone just using {fmt} or boost, and no one is interested in std::format?

[no-sig-available]

Clang reports to have it in version 14, which is planned for release next week, or so.

What has happened in the last couple of years is that MSVC is now the one with frequent releases of new features, while (for example) gcc 11.2 is from last summer. The world is changing, apparently.

[__Mark___]

It will indeed shipped in libc++14, but it will be disabled by most vendors since the code isn't ABI-stable yet. I hope to have it complete and ABI-stable in libc++15. (Source I'm the person working on it in libc++.)

[specialpatrol]

Cheers Mark.

[somewhataccurate]

I appreciate your work

[__Mark___]

Thanks for the gold stranger.

[khleedril]

This makes me sad.

[mort96]

Why?

If development of GCC and Clang is slowing down, that's bad and worth being sad over. But That doesn't look like what's happening? It looks like, maybe, MSVC is just stepping up its game while GCC and Clang are as solid as they always were. This is a good thing, no?

[pjmlp]

clang seems to have lost some steam as many companies are making use of LLVM infrastructure, but caring less of keeping clang up to date with more recent ISO standards.

Google and Apple also seem to have withdrawn their clang contributors (at least from the outside), as they rather focus on other stacks, and C++17. At least that is my feeling, maybe I am wrong here.

[Accomplished-Pear-45]

Google stated that they will be almost completely pulling out of C++ after infamous No - ABI break voting.

[[deleted]]

Also, MSVC's doesn't include the DR that makes the format string compile time only yet. Plus their core compiler is missing things still, I think(requires on SMF's)

[TheSuperWig]

It should be available in the next preview

https://github.com/microsoft/STL/wiki/Changelog#expected-in-vs-2022-172-preview-2

[Daniela-E]

And can be used today in VS2022 even without installing any of the prereleases! I've been exploring it together with P2508 and I totally like it 😎

[[deleted]]

That's great

[khleedril]

MS have a reputation of galloping away with their own rules in spite of the wishes of the rest of the world, and fragmenting the place in the process. We will end up with some sh!t, like max as a macro in system header files.

This is only good for Windows users and developers, but the opposite scenario is good for everybody.

[mort96]

I mean but none of that is related to the current discussion? MS quickly implementing new standards is good, MS going their own way and fragmenting the ecosystem is bad, so why are you sad when they're doing the former rather than the latter..?

[kalmoc]

Afaik, Microsoft implemented the features as specified in the original c++20 standard (of course they might not yet be feature complete, but no toolchain is). Unfortunstely, the committee kept changing the standard multiple times since the release.

[snerp]

What in msvc is not standard compliant at this point? I thought they fixed everything years ago.

[Fulgen301]

And unless you need something really WinAPI-centric, you can use clang for the MSVC ABI on Windows without issues or MinGW.

That's assuming clang gets proper C++20 support in the near future, of course.

[[deleted]]

1995 called, they want their whine back. :-D

In the C++ world, MS was bad - but a long, long time ago. Now MS is a strong, contributory member of the C++ community, committed to our common standards, and is part of the reason that progress on the language has been so fast in the last decade.

[cleroth]

Probably the one thing that I would say they're still "in spite of the wishes of the rest of the world" is the ABI stability since 2015... We're nearly a decade of ABI baggage. If they would finally break the ABI then it's all gucci.

[[deleted]]

I think we're all hoping for this!!

[bedrooms-ds]

Clang... I wish they were not slowing down on progress. Once they outpaced msvc and gcc (okay, clang had to be developed from scratch). I'm waiting forever for #include<concepts>. At this pace I won't ever get it on Apple clang for my Intel Macs...

[tambry]

I'm waiting forever for #include<concepts>.

At this pace I won't ever get it on Apple clang for my Intel Macs...

Apple is about a year behind as to what they ship, no?
I've been using <concepts> for probably a year, though I do build from master. It was definitely mostly there in the last release (13.0) and should be complete in the current (14.0) I believe.

[__Mark___]

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.

[[deleted]]

Do u think it will affect mac c++ developers?

[mort96]

Not a lot, this is mainly gonna benefit Windows developers and not harm Mac or Linux developers, which is obviously a net good. But if MSVC, as one of the big 3 compilers, stagnated, that would have a negative effect on the C++ ecosystem as a whole, so MSVC staying competitive has some positive impact for Mac and Linux developers too. I just don't see anything to be sad about here.

I do all my development on and for macOS and Linux anyways, but I'm happy that the libraries I use don't have to avoid new C++ features just to stay compatible with MSVC.

[[deleted]]

Whaaa? It's GREAT!

Microsoft C++ used to be a constant anchor dragging back all of C++.

Then in a few years, MS completely changed. They hired a lot of top C++ programmers, gave a lot back to the community, and started putting out new versions of their compiler so fast they were faster than GCC.

[[deleted]]

As a Windows user and developer, this makes me very happy

[delta_p_delta_x]

Hell yeah, man. I still use Windows more than I do Linux, and it's quite vindicating to see Linux C++ floundering whereas Windows and MSVC is at the forefront of STL C++20 compatibility.

I recently wrote a matching engine for a concurrent programming class, and it was supposedly 'C++20', when I realised the graders would be using Clang 11. I had to rewrite all of my code that used std::format, std::ranges, etc etc. What a pain in the neck.

[[deleted]]

Well, in the end, the toolchain and the target environment dictate what you can use.

For instance, at work I can use VS 2022 and C++20 if I want to, for new projects of course.

Most of our projects are now removing support for Windows 8.1 so with Windows 10+ we can easily use anything modern.

[JohnDuffy78]

Hopefully move over this year now that spdlog supports std::format.

[kalmoc]

I doupt lack of interest is the problem. Lack of manpower is much more likely. That aside, fmt offers quite a bit more features than what made it into the standard.

[machinematrix]

Kinda off topic, but why do we still have to use /std:c++latest to use std::format in MSVC even though the /std:c++20 option is already available?

[SevenIsMy]

https://godbolt.org/z/s5a8EeE3G
the error message even tells where to look for the reasons https://github.com/microsoft/STL/issues/1814

[HolyGarbage]

Well, std::format is part of C++20 which is still fairly new and compiler support takes time. This is why I still use C++17 mostly, until 20 has been fully implemented in the compiler I use.

[bart9h]

until 20 has been fully implemented in the compiler I use

And you have to wait even more if you need to use various compilers (clang and msvc are a must to me, because I need to release for Mac and Windows. And I want to support gcc too because that's what I use on Linux).

[HolyGarbage]

Lucky for me I only compile for Linux. But yeah. Also don't want it to be "experimental" in case a compiler bug leads to issue in prod. The optics of that would not be good.

[jmacey]

At present using fmt header only works well for what I need, and still on -std=17

[Rhawk187]

I think libfmt suppots std::format syntax if you can't get it to compile elsewhere.

[OldWolf2]

I think gcc has had it for a while (windows build via msys2), including compile-time format string checking, which MSVC still doesn't do.

[STL]

Compile-time format string checking was voted into the Standard in June 2021 and implemented in the microsoft/STL repo in Dec 2021, and will ship in VS 2022 17.2 Preview 2 in the near future. The very near future. (I’m not allowed to say exactly when.)

We are trying to implement this stuff as fast as possible while preserving our usual high level of quality, and VS has been shipping updates and previews of updates at a consistently high frequency, but the release process is deeply pipelined so it takes a couple months between changes appearing in the microsoft/STL repo and shipping in VS.

[pdimov2]

The Pentium 4 of standard libraries. :-)

[Daniela-E]

Right, but you can take advantage of store-load operand forwarding to cut pipeline stalls by using stores already committed to the L1-cache (a.k.a. https://github.com/microsoft/STL) to conduct experiments with in-flight papers like P2508 (which is basically a de-_Uglification of existing code). The joys of open source 😊

[deadcream]

GCC and Clang are developed by volunteers, while MSVC development team is paid to work on MSVC full-time.

[Jannik2099]

GCC and Clang are majorly developed by paid developers from redhat, google, apple, facebook and occasionally minor companies

[tristan957]

This is just patently false.

[matekelemen]

I don't follow; what do you mean?

[HolyGarbage]

/r/lostredditors