MaxEW707 wrote: > (@MaxEW707 I think having a chat about this informally would be nice.)
Sounds good. Let me know the best way to contact you. > While I disagree with the reasoning for not just using std I'll try to give more context here. The main reason is include times and not wanting to work around a variety of vendor STLs who have widely different include times and behaviours. For clang we need to worry about 5 different STLs: MSVC STL, libstdc++, libc++, a vendor STL and some vendor forks of libc++. There are larger issues here when dealing with shipped vendor STLs that are custom or forks of libc++ that we can talk about offline. On one of our smaller projects the PC build is ~16,000 cpp files which includes the generated cpp files, the tools, engine, tests, and the game itself. This is the build that most engineers work on and they usually need to work across a variety of domains since a change in the engine may require a change in the code generator, editor, asset building, the unit tests, the integration tests, etc. On this smaller project one of our console builds which only includes the game itself is around ~4k source files when I last checked. Just adding `#include <new>` to our `corelib/placement_new.h` header increased build times by ~22 seconds. On this platform the vendor STL `<new>` took 29ms to parse so that means that header was roughly included into ~750 files. That is a build time increase for one file include that we cannot at all live with. We do not use the STL anywhere in our code base. We have our own so just including any STL header also brings in other headers like `type_traits` and their config headers. On MSVC STL it brings in `yvals_core.h` and its dependencies. For us these headers are never amortized because a cpp file might use `<string>`, `<vector>`, `<new>`, etc from the STL. At the end of the day we don't want to deal with different STL implementations. We do not use STL and do not want to include it. We do not agree with a lot of language level features like move, placement new, etc being implemented in the std. We would prefer to just have compiler builtins for us like `__builtin_launder` and `__builtin_addressof`. A lot of std headers also aren't small. `<utility>` is huge when I just need `move` and `forward`. `<new>` is massive when I just need placement new because we do not at all ever hit global new. libc++ is getting better here, https://libcxx.llvm.org/DesignDocs/HeaderRemovalPolicy.html, but we still have to deal with MSVC STL, vendor STL and vendor forks of libc++. We would rather just have compiler support that everyone can use instead of relying on the STL to implement language level features especially given how much the compiler is being asked to poke into the std lately. In my view C++ should not require the STL to "work". I shouldn't need a library to use a language. https://github.com/llvm/llvm-project/pull/76596 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
