papers VS stl-header-heft

The interpretation is probably up for some debate especially since meeting details are not public, but some relevant links are:

- The P3390R0 Safe C++ proposal and the related vote in the 2024-11 Wrocław meeting: https://github.com/cplusplus/papers/issues/2045

- The adoption of the paper P3466 R1 (Re)affirm design principles for future C++ evolution at the same meeting, which contains language which can be interpreted as preemptively foreclosing a Safe C++-style approach: https://github.com/cplusplus/papers/issues/2121

And yet, there is a good chance that C++ will start doing exactly this [1]. Because [2]:

> The performance impact is negligible (less that 0.5% regression) to slightly positive (that is, some code gets faster by up to 1%). The code size impact is negligible (smaller than 0.5%). Compile-time regressions are negligible. Were overheads to matter for particular coding patterns, compilers would be able to obviate most of them.

> The only significant performance/code regressions are when code has very large automatic storage duration objects. We provide an attribute to opt-out of zero-initialization of objects of automatic storage duration. We then expect that programmer can audit their code for this attribute, and ensure that the unsafe subset of C++ is used in a safe manner.

> This change was not possible 30 years ago because optimizations simply were not as good as they are today, and the costs were too high. The costs are now negligible.

[1] https://github.com/cplusplus/papers/issues/1401

[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

For whatever its worth, if we wait long enough C++ will include the equivalent of `malloc_good_size`. https://github.com/cplusplus/papers/issues/18

https://github.com/cplusplus/papers/issues/1668#issuecomment...

Looks like it did very well in St. Louis!

It is slowly making its way through the standards committee. https://github.com/cplusplus/papers/issues/43

The author has a fork of clang and gcc with some pretty impressive speedups, so I’m hopeful! https://lists.isocpp.org/sg14/2024/04/1127.php

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884

Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

> The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code).

Additionally,

> Another problem is formatting of Unicode text:

> std::cout << "Привет, κόσμος!";

> If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

See https://github.com/cplusplus/papers/issues/557

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

The older I get the more I think #include in public headers needs to have a whitelisted regex git push filter, and the permitted whitelist of permitted includes is small and excludes most of the standard library. https://github.com/ned14/stl-header-heft, after all.

As you know, every two years or so I update https://github.com/ned14/stl-header-heft and historically the only STL to shrink in terms of token count has been yours, albeit starting from a high initial base. libstdc++ consistently grows. I look forward to discovering how VS2022's STL compares to preceding editions.

You may want to have a look at https://github.com/ned14/stl-header-heft too :)

string_view drags in a ton of the STL. string_view cannot deallocate on destruction. See https://github.com/ned14/stl-header-heft.

Even million line C++ codebases can compile from scratch within minutes if your header files never include anything not in the least impact headers list from https://github.com/ned14/stl-header-heft.