Registration is now open for CppCon 2023! The conference starts on October 1 and will be held in person in Aurora, CO. To whet your appetite for this year’s conference, we’re posting some upcoming talks that you will be able to attend this year. Here’s another CppCon future talk we hope you will enjoy – and register today for CppCon 2023!
Monday, October 2 • 16:45 - 17:45
by Luis Caro Campos
Summary of the talk:
C++ modules are one of the most talked-about features introduced in C++20, but are still not widely in use. One of the biggest promises of C++ modules is to reduce overall compilation times by removing the need to have the compiler parsing the same include files across a big number of translation units. However, despite available compiler implementations, modules are still not generally in use. Why is this?
When put into practice, C++ modules introduce a dependency in the order in which translation units are built: in order to build a source file that contains a module import statement, the source file that exports the name module needs to have been compiled into a binary module interface beforehand. This calls for compilers and build systems to work together to correctly derive the order in which source files need to be compiled.
To overcome this, paper P1689 has been proposed for compilers to report the dependencies between source files, so that build tools (e.g. CMake and Ninja) can use this information to derive the correct build order. However, the currently available implementations have limitations and where all the source files that export module definitions should be visible by the same build.
How does this work in scenarios where we have dependencies (e.g. third-party) that are provided externally to the current build system? We have become accustomed to a model where a “binary” package contains, at the very least, header files (.h/.hpp) for the compiler, and libraries (.a/.so/.lib/.dylib) for the linker. How do modules fit into this model when it comes to installing and distributing prebuilt binaries? Now more files are required on the consuming side: the compiled binary module interface, and the corresponding module interface source file.
This talk will review the current state of modules in C++, by presenting the experience currently provided by the most recent versions of the relevant tools. Special focus will be put on the potential of using C++20 modules for external library dependencies, and how far we are from being able to consume external libraries using modules.