>From a users perspective, having STL modules would speed up compilation times immensely. The current problem is that if we want to improve compile speeds, we pre-compile the STL parts we use. We either pre-compile everything to save programmer time and not care what parts we’re using (PCH becomes HUGE), or we selectively manage (tedious to update CMakeLists.txt for every #include we add). Also, if the PCH changes, we take a large hit for updating it.

If the group seems decided that the definition / implementation of STL entities would need to be shuffled around anyway for proper modular design, I’d argue that creating a module for every STL header still has its benefit:

• Build systems would pick up module dependence automatically, just like with headers
o No need to micro-manage target_precompile_headers
• No compilation time hit for adding-removing modules (not headers)
o Currently all throwaway / toy code pays the price
o PCH gets recompiled for every CMake config change

If ODR stands with headers, it should do too with modules, given every header is its own module. (It would likely even stand when mixing modules and headers: for eg. import a std module and include a boost header after, which in turn includes std headers.) Not nice, but just by changing #include to import, compile times would improve to always using just the right amount of PCH. That alone is a great deal.

Would this be worth the effort?

Feladó: Bryce Adelstein Lelbach aka wash via SG15
Elküldve: 2020. március 9., hétfő 5:48
Címzett: Michael Spencer
Másolatot kap: Bryce Adelstein Lelbach aka wash; Ben Boeckel via Modules; ISO C++ Tooling Study Group; C++ Library Evolution Working Group; Evolution Working Group mailing list
Tárgy: Re: [SG15] [isocpp-ext] Modularization of the standard library andABI stability

What is the benefit of modularizing the standard library in C++23, given that standard library headers (modulo a few like <cassert>) are already importable?

On Sun, Mar 8, 2020, 21:31 Michael Spencer <bigcheesegs_at_[hidden]> wrote:


On Sun, Mar 8, 2020 at 2:01 PM Bryce Adelstein Lelbach aka wash via Ext <ext_at_[hidden]> wrote:
Do we have any ABI stability concerns regarding modularizing the standard library? Certainly for strong module ownership implementations, this is a concern, but for weak module ownership implementations it may be a concern too, because the mangling of internal implementation details with module linkage would change.

Can implementations overcome this with special hacks for the standard library that preserve the old mangled names?

I don't expect stdlibs to move off of headers in the foreseeable future (in order to support pre-modules compilers and build systems). Given this I expect standard library entities to remain the in global module, and thus the named module they are exported from to be irrelevant. If someone writes a new C++20+ only stdlib then they will have a different ABI anyway, but there would then be potential ABI breakage from moving an entity. However, it is not observable which module an entity is from, so it's quite easy to work around any ABI changes that would occur due to moving where an entity is. I seriously doubt we would remove a declaration from a module without removing the declaration entirely though, which is the only way you would end up needing to change which module owns it.


- Michael Spencer