Scorpion
It has been a while since the last time we shared updates on C++20 modules. In the past period of time, the entire development team, including the tool set, project system, and IDE team have been working hard to provide C++ developers with a superb C++20 module experience. Today we will talk about what we do. What happened. Are you sitting still?
What are the new things?
/std:c++latest implicitly includes C++ modules
Since MSVC has begun to implement the C++ module standard, the tool set will force the use of the /experimental:module compilation switch at any time. Because the module has been officially moved to C++20, the compiler community has done a lot of work and finally merged the module into /std:c++latest.
There are the following points to note about /std:c++latest :
> /std:c++latest now implicitly includes /permissive-. This means: Customers currently relying on the licensing behavior of the compiler in combination with /std:c++ latest must now apply /permissive on the command line. Note: Enabling/permissive will disable the module.
> Now that the module has been converted to the latest language mode, some codes may not work because modules and imports are converted to keywords.
We have documented some common scenarios. There are more options for the file conversion module implemented by MSVC and importing keywords, please refer to P1857R1.
> The standard std* modules included with Visual Studio cannot be used by /std:c++latest alone. The standard library module has not yet been standardized, so it is still in the experimental stage. To continue using standard library modules, use /experimental:module as part of its command line options.
Dedicated module fragment
C++20 adds a new part to the main module interface, called the dedicated module fragment [module.private.frag]. The dedicated module fragment allows the code author to truly hide the details of the library without having to create a separate C++ source file to contain the implementation details. Imagine using PIMPL mode in the main module interface, as shown in the following figure:
Below is the code to import the client
The private module partition is an abstract barrier that can free the users of the containing module from any restrictions defined in the permissions of the private partition, thus effectively making a single "head" library have better sanitation, improved packaging and reduced construction System Management.
The header file contains
After the header file unit is introduced, the conversion of the header file inclusion becomes possible. [cpp.include]/7 enables the compiler to convert the #include directive to the import directive, provided that the header file name specifies importable (for MSVC, through Use the /headerUnit header file unit to mark the header file as importable).
You can use C/C++ -> All Options -> Other Options and add /translateInclude to enable this compilation switch. In future versions, users can choose the specific header file unit they wish to include conversion, rather than a simple all-or-nothing switch.
Module link
In addition to simple (front-end) analysis, C++ modules have higher requirements for the toolset.
C++20 introduced a new form of linking, namely "module linking" ([basic.link]/2.2). Using only front-end name modification, the proof of concept for the realization of module links developed in the era of module technical specifications (TS) has proven to be incomplete and inefficient in terms of scale. Starting with Visual Studio 2019 v16.8, the compiler and linker work together to enforce module linking semantics (no front-end name processing required). The new linker means that users can use named modules to write code more freely, without worrying about name conflicts that may occur, and at the same time obtain stronger odr guarantees that no other language tool can provide.
Strong Ownership
The MSVC toolset also uses a strong ownership model to implement program linkage. The strong ownership model gives the linker permission to attach the exported entity to the module to which it belongs, thereby bringing certainty and avoiding link name conflicts. This feature allows MSVC to exclude undefined behaviors caused by linking different modules (possibly revisions of the same module) that report similar declarations of different entities in the same program.
For example, consider the following example, which demonstrates an undefined behavior:
In practice, in general, we will not deliberately write such code, but it is difficult to avoid this situation under code migration, evolution and maintenance.
This type of program (with two external link names with munge) cannot be used without strong module ownership semantics. Strong ownership can implement new odr guarantees. There is a good paper "A Module System for C++", which introduces the principles behind strong ownership in detail. You can refer to it.
Engineering system
The most important part of using C++ modules may be to have a build system that can meet the requirements for building C++ modules without a steep learning curve. The VC engineering team has been working closely with the compiler tool set team to bring automatic module and header file unit support experience, thereby minimizing the user's settings for them.
A file with the extension .ixx or .cppm is regarded as a "module interface" file, but ultimately it is controlled by the CompileAs attribute, as shown in the following figure:
If you want to build a header file unit for the .h header file, you need to change its item type to "C/C++ compiler", because by default, the .h header file is in the "C/C++ header file" group and does not Will be passed to the compiler. By default, "C/C++ Compiler" files with a .h extension are regarded as "header file units", as shown in the following figure:
The project build will automatically scan the Modules and Header Unit files (according to its "CompileAs" setting) to find other Module and Header Unit dependencies in the same project, and build in the correct order of dependencies.
To reference a module or header unit produced by another project, just add a reference to that project. All "common" modules and header file units in the referenced project can be automatically used for code reference.
A project can control which modules and header files (including modules built as header files) are considered "public" by modifying the following properties, as shown in the following figure:
Compiler switch
The experimental phase of many compiler switches prefixed with /module: has ended, so we have moved them to a new official name.
As shown in the following table:
IntelliSense
Without IntelliSense, the visualization of Visual C++ is greatly reduced. In v16.8, we added full support for using IntelliSense in modules, including the ability to write module interfaces (.ixx) and obtain context information from imported modules and header file units.
IntelliSense support for imported modules will not be provided in Preview 3, but we plan to enable it in the upcoming preview version. Please continue to pay attention to our CppCon demo, we will demonstrate how to use IntelliSense.
The tool set development team has been working hard to ensure that the C++ module format issued by the compiler is fully documented and can be used stably in the IntelliSense engine. MSVC is responsible for building the IFC file, and then the IDE will use this file. The ability of other tools to use the MSVC IFC format is critical to a healthy ecosystem, and the IntelliSense engine using IFC output is the first step in this direction.
to sum up
It's still coming, complex C++.
I promise that in my next life, I will use C++ modules and will never break my promise.
At last
The blog of the Microsoft Visual C++ team is one of my favorite blogs. It contains a lot of knowledge about Visual C++ and the latest developments. If you are still interested in the ancient technology of Visual C++, you can often visit them (or me).
This article is from: "Standard C++20 Modules support with MSVC in Visual Studio 2019 version 16.8"
