lefticus
How C++20 Modules can change the way we design libraries.
Channel
"C++Weekly"
Topics
How C++20 module affect the way we design libraries? Often libs are used to hide implementation details and dependencies. Now since Modules has accessibility permissions in the form of private and public (aka exporting and not exporting) you can use a module to hide dependencies and implementation detail types.
For example, you used to have a Dx12Gfx and a VkGfx lib and a Gfx lib. The Gfx lib would expose the public interface and would be implemented by using Dx12Gfx and the VkGfs lib. Now we can have 1 lib and 3 modules instead and not fear that you pollute your namespace with the type of the implementation detail like D3d11Texture,...
Length
I would go for more long-form (10-20 minutes), to explain trade off, pros and cons
Perhaps additional expansion on this question in a follow-up episode...
Can C++20 Modules change the way library authors deliver binaries to their 'customers'?
- Can I supply a shared library binary plus a Module Interface File for importing instead of a shared library binary plus a traditional Header file for includeing?
- What about supplying a BMI file and object file plus Module Interface File? Any opportunity for delivering that format instead of a static library and header? If so, any pros/cons?
- Can linking binaries with their interfaces described via Modules instead of via traditional Headers help overcome issues with ABI mismatch? i.e. compile-time failure instead of run-time UB?
