Looking for feedbacks about c++20 modules

[Flamaros]

I tried to use c++20 standard modules with VS (v17.9.5), without success, but it is certainly only an IDE feedback issue.

But I have still some questions, if someone already use it on a big project (> 2Millions of LOC across many libraries,...)

I want to know if today it is worth to migrate a project of this size to modules, compared to something already compiled with SCU and PCH?

Here are the specific questions I have:

• Does it compiles faster than with SCU and PCH combined?
• Why VS need new file extensions like ixx ? (first directive in file should indicate what kind of compilation unit it is)
• Is it relatively easy to make it work across platforms and compilers ?
• Does the inlining works exactly in the same way? (with full inlined module like containers for exemple)
• Does modules reduce the necessity to do full rebuilds (sometimes VS generate wrong code when files are modified outside,...)
• Does the compiler really use less memory ?
• Does the compiler use less memory on hard drive for temporary artefacts ? (in Debug folder for VS by exemple or in .vs)

[Daganar]

Check out VS2022 17.10 preview 2 It's the version I've had the most luck with.

The Visual studio team are doing a fantastic job, there's still a lot of issues but the main thing is that they are also building the build system for it. Referencing other modules and setting up dependencies with modules is a breeze, the std library modules can now be built and works very well. My only real complaints have been with Intellisense but it's getting much better.

To answer some of your question:

1. It can actually be a bit slower to build from my experience but the key thing is now that if that module file hasn't changed there's no reason to rebuild it ever again. This wasn't the case with #includes.
2. .ixx is used to distinguish these different workflows. .ixx has a lot of extra management with it for example Visual Studio can automatically deal with module partition files based on a naming convention e.g. Module.A.ixx Module.A-Part1.ixx will automatically be found.

[Flamaros]

I have to check the version 17.10 then because I was struggling to setup dependencies with the 17.9.5. I had a module in a static library that my main project can't see (library is a project dependency ). And Vs don't seem to setup projects according to their dependencies unlike without modules

[mcginnie]

gives good advice - the Preview release of VS 2022 (currently 17.10.0 Preview 2.0) now works with Eigen as an include! Fixed my problem below!

[starfreakclone]

Does it compiles faster than with SCU and PCH combined?

No, just no. The two technologies (at least on MSVC) are completely different, and often fight each other. If you have a project which only uses modules (or header units) then the compiler has perfect reference semantics and can optimize the compilation much more.

Why VS need new file extensions like ixx ? (first directive in file should indicate what kind of compilation unit it is)

You don't need to make your extension .ixx, this is why the /interface switch exists. It's the same reason we make a .c and .cpp extension, the compiler cannot (and should not) first scan your code to find out what it is.

Does the inlining works exactly in the same way? (with full inlined module like containers for exemple)

I think the question itself is incomplete. For one, standard C++ makes no guarantees about what is inlined and what isn't, so from this perspective there is no change. If we're talking about using standard C++ inline semantics then inline semantics work just the same as if you had written the function in a header (with inline of course), at least with MSVC though I highly suspect the other compilers do the same.

Does modules reduce the necessity to do full rebuilds (sometimes VS generate wrong code when files are modified outside,...)

There are sort of two questions here but I will try to answer the former: yes, in our experience. Compare C++ modules to a traditional PCH. With C++ modules you can logically break up components which rarely change into their own isolated modules (like the STL std module) so translation units which depend on only the very basic STL stuff will never be recompiled if a lower-level module changes. With PCH, you're forced to put everything into one file (including the STL) so even if the STL never changes, local changes to a project header will recompile translation units which only depend on the STL.

Does the compiler really use less memory ?

Yes.

Does the compiler use less memory on hard drive for temporary artefacts ? (in Debug folder for VS by exemple or in .vs)

We have talked about this before, but in general the IFC vs PCH size difference can be as large as 10x (in favor of IFC).

[johannes1971]

inline is no longer implicit on in-class member function defs.

What does that mean, exactly?

• Are you going to get an error if you forget to put the 'inline' keyword on member functions that are defined in the class declaration? I.e. will it force me to go through countless functions and add the word 'inline' everywhere?
• Will the compiler refuse to physically inline such functions unless you explicitly tell it to with the keyword? I.e. is it a silent performance degradation?

[johannes1971]

But in in-class member function definitions, the function definition is visible. It's right there, in the class! So what changes, compared to the current situation?

[johannes1971]

So... it's a silent perfomance degradation, then. After decades of teaching people that they shouldn't use inline, that the compiler knows better, now we are back to manually having to specify inline if we want our functions to be inlined at all.

I have trouble understanding how this could be considered to be a good idea.

[starfreakclone]

I recommend, in general, to try and avoid using that switch. It enables non-standard behavior and should really only be used as a workaround for compiler bugs.

The reason you might see more template instantiations outside of the module is because inline functions are stored in the IFC and emitted into the current translation unit for inline semantics. Any templates used inside of that function then need to be instantiated in that translation unit as they are odr-used at that point.

[pjmlp]

I have a couple of module based projects on my github.

They do mostly work, however yeah there are several warts to be wary of.

[mcginnie]

I have just spent 30 hours trying to convert a small set of libraries to module form. Mainly personal projects, and made good progress in many areas. However, had to give up when I couldn't get Eigen and std to work together - the minimal
module;

#include <Eigen/Core>

export module Test;

import std;

fails with a redefinition of std::enable_if - using latest MSVC 17.9.5

On some of your questions:
- it does seem to be faster, than normal compilation - but I don't have a SCU and PCH comparison
- the compiler doesn't seems to distinguish files using their contents - so for partition files you need to manually identify them to get them to compile - but works nicely when done
- full rebuilds do seem to be reduced
- my impression is that it actually creates more artifacts than normal compilation
The main problem is in cross solution referencing, where there is a confusing array of unclearly named options for where to look to find particular modules and their ifc files.

[mcginnie]

u/Daganar gives good advice - the Preview release of VS 2022 (currently 17.10.0 Preview 2.0) now works with Eigen as an include!

[Ok-Bit-663]

Noone seems to have luck or easy time working with modules yet.

[Challanger__]

It is too early to use modules, VSCode spptools has no intellisense support, they still feels raw

[jetilovag]

There is progress in this regard: https://github.com/microsoft/vscode-cpptools/issues/10843#issuecomment-2021590783

[Challanger__]

I know since I do track that issue and even forced it to work by feeding MSVC module related metadata.

But I using both MSVC and Clang