Mastodawn

yes, I am aware.

I just thought Jason covering it, would be good opportunity to broaden awareness of the real cause of the issue (QoI) and that we can hopefully expect improvements.

stdlibc++ needs to follow suit...
waiting for MSVC might take a long time.

@oschonrock They are all aware. The problems is that WG21 has been dumping tons of garbage and the number of maintainers is very low.

I think there are plenty of non-committee people who are not aware that <format> and <print> compiling at turtle speed and bloating binaries to supernova size is a pure QoI issue...

Even Jason didn't really make that clear in his video. I assume he knows, but most of the audience doesn't, as can be seen by the comments.

@oschonrock They are not really bloating binaries that much, "only" object files. The final binary should still have one copy of all formatting code.

@oschonrock I'm fine with youtube "experts" throwing shit at current standard library implementations of std::print until the latter are improved (and possibly after)

Oliver Schönrock

I agree...

However, many of the comments are:

"the committee is crazy, they standardised garbage".

incorrect, but that's the most popular misinterpretation.

@oschonrock I mean, have you seen youtube comments in general?

yes, they are horrific....,

but it would help everyone, if someone like Jason, who is perhaps one of the best known communicators in the community, would say:

"there is no need for these to be slow to compile or to produce binaries which are bloated and you can't effectively inspect in CE. Look at fmtlib... this i is a QoI by the vendors"....

@oschonrock that's more of an ask to @lefticus

@vitaut @lefticus

it is... but I was suggesting that you should ask him...

he is more likely to do it then ;-)

Jason Turner Mar 9

@oschonrock I mean I thought I did imply that it's possible to do it better since {fmt} does do it better.

@lefticus

You did... too subtly IMHO.

Those compilation speeds make <format> and <print> basically unusable, not just on CE, but locally as well.

and this is since c++20.

Jason Turner Mar 9

@oschonrock well if history is any indicator, someone who implements this will probably see it.

But really the implementers are overworked already, IMO.

@lefticus

I am sure that is correct.

It's unfortunate that the perhaps "the most mainstream feature"

ie "how to print hello world"

remains borderline unusable after so many years. Affects a lot of people.

But I guess everyone says that about their pet feature?

@oschonrock @lefticus Note that print is 23. I'm more concerned that std::string is unusable but Jonathan Wakely promised that they'll fix it anytime now.

Oliver Schönrock Mar 10

@vitaut @lefticus

Yeah but <format> is most of the feature.

vitaut 🤍❤️🤍 🇺🇦Mar 10

@oschonrock @lefticus Interestingly you can improve them completely independently.

@vitaut @oschonrock @lefticus

Peter Sommerlad Mar 10

what is the underlying issue with std::string in libstdc++?

@PeterSommerlad @vitaut @oschonrock @lefticus

J.W.Mar 10

I _think_ he means that for C++20 we don't enable the explicit instantiation declarations (i.e. 'extern template') for std::string, so everything that uses std::string in C++20 (and later) compiles slower than in C++17 mode. And of course std::format uses std::string.

It's on our TODO list, but I don't want to make changes to the exported symbols until closer to the GCC 16 release. Which is getting very close now.