@vitaut

compile time and binary size of the stdlib implementations of format and print.

watch the video.. it's only 7mins

@vitaut

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 @vitaut

Sigh. Firstly, it's libstdc++ not stdlibc++.

Secondly, no, we don't need to. The overhead of <print> is known, and expected. We don't export any C++23 symbols from libstdc++.so yet, so that we can still change things before we are stuck with a stable ABI forever. That means the entire std::print implementation is inline and has to be instantiated and emitted in the TU, instead of just linking to a library function. The choice is to freeze the ABI early and have people complain for eternity, or delay it until we're ready and have people complain about compile times for a year or two.

I suppose what we could do is make it conditionally non-inline, so that if you define a macro like _GLIBCXX_PRINT_EXTERN and link with -lstdc++exp you'd get a non-inline definition. It's not a priority though. As usual, we're focussing on adding features and on correctness, before we try to prematurely optimize.

@vitaut
Yeah for std::format it wouldn't be premature, but GCC 16 will be the first release with complete and stable C++20 support. It's time to optimize it now.

For std::print we're still working on it, and we're not pretending it's optimized or stable yet. Feedback is useful, but entitled demands to fix things tend to have the opposite effect on how I decide on priorities.