stl-header-heft
zapcc
| stl-header-heft | zapcc | |
|---|---|---|
| 5 | 4 | |
| 53 | 1,238 | |
| - | - | |
| 0.0 | 1.8 | |
| over 3 years ago | almost 4 years ago | |
| Python | C++ | |
| - | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
stl-header-heft
-
"Fast Kernel Headers" Tree -v1: Eliminate the Linux kernel's "Dependency Hell"
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.
-
C++23: Near The Finish Line
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.
-
C++ Library Include Times: Time it takes to #include any standard library and other headers
You may want to have a look at https://github.com/ned14/stl-header-heft too :)
-
zpp::throwing<T> - Implementing "almost" C++ exceptions with coroutines
string_view drags in a ton of the STL. string_view cannot deallocate on destruction. See https://github.com/ned14/stl-header-heft.
-
Why is this channel less active?
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.
zapcc
- In 10 years, Clang has become 2x slower, but generates code that is 10-20% faster
-
"Fast Kernel Headers" Tree -v1: Eliminate the Linux kernel's "Dependency Hell"
C++ modules helps with the parsing problem similar to precompiled headers, but it doesn't help with the code execution at compile time problem. All your overload matching, free function lookup, SFINAE, concept matching, and consteval code needs executing and that can take very considerable time. Other than JITing all that stuff, and maybe running an in-memory server like https://github.com/yrnkrn/zapcc, I don't know what more can be done here.
- Zapcc: A caching C++ compiler based on Clang
-
Distcc – distribute builds across multiple machines simultaneously
If you use clang, that might be of interest: https://github.com/yrnkrn/zapcc
What are some alternatives?
papers - ISO/IEC JTC1 SC22 WG21 paper scheduling and management
termux-ndk - android-ndk for termux
stdBLAS - Reference Implementation for stdBLAS
sccache - Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible. Sccache has the capability to utilize caching in remote storage environments, including various cloud storage options, or alternatively, in local storage.
papers
ayanami-nemesis-analyzer - A C/C++ Staitc Analyzer for Now.
include-what-you-use - A tool for use with clang to analyze #includes in C and C++ source files
lua-clang - Build dynamic clang library for lua
plf_colony - An unordered C++ data container providing fast iteration/insertion/erasure while maintaining pointer/iterator validity to non-erased elements regardless of insertions/erasures. Provides higher-performance than std:: library containers for high-modification scenarios with unordered data.
ClangBuildAnalyzer - Clang build analysis tool using -ftime-trace
zpp_throwing - Using coroutines to implement C++ exceptions for freestanding environments
opencilk-project - Monorepo for the OpenCilk compiler. Forked from llvm/llvm-project and based on Tapir/LLVM.