VS 2022 17.5 Preview 1 and std module

[matbech]

As per the Changelog, Standard Library Module std is available in VS 2022 17.5 Preview 1. Is there something special that needs to be done as it doesn't seem to be working out of the box. I'm getting the following compile error when importing std:
error C2230: could not find module 'std'
with /experimental:module
The "V143 modules (experimental)" individual feature is installed as well.
Importing the legacy std.core module works without any errors though.

I got it working by creating a new C++ static library project, then I added the std.ixx module file from the modules folder:
C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32019\modules
$(VCToolsInstallDir)modules\std.ixx
and then I referenced this new project.

Is there another way?

[davidhunter22]

I just added the std.ixx file directly to my project, I didn't need a separate library.

I'll cheekily add my question here. If i do

#include <string>
import std;

should I expect it to work?

[matbech]

David Hunter (@davidhunter22) Assuming you meant import std; and not using std; that was not working with the legacy modules (std.core) either because the #include comes after the import. However, the following where the #include comes before the import was working:

#include <type_traits>
import std;
std::vector<int> items;

which now fails to compile:
C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32019\include\xtr1common(42,47): error C2572: 'std::enable_if': redefinition of default argument: parameter 1

[davidhunter22]

Thanks Mathias Berchtold (@matbech) I updated my question

[fsb4000]

Is there another way?

I think you don't need another static library project. Just add std.ixx to your Source Files and it works.

(Add -> Existing Item... -> C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32019\modules\std.ixx)

[fsb4000]

should I expect it to work?

David Hunter (@davidhunter22) , probably it should work, but the compiler has bugs.

I have found in the Discord channel:

[davidhunter22]

One sad thing I noticed with adding the .ixx file to a project. If you have a solution with 200 projects and all of them add the .ixx file then you compile the standard library module 200 times. This does only happen on the first build but :-(
Hopefully MS will tell us a better way than this so that you only build it once per solution

[davidhunter22]

Not being able to mix "import std" with classic includes is a real pain. Any large body of code these days probably uses third party libraries, in my case from vcpkg. Almost all of them will #include standard library header in their headers. So you can't migrate your code to use import std until every library you depend on either has a build varaint that uses the std module or has a macro to guard #includes in it's headers. As in

#if defined( DONT_INCLUDE_LEGACY_HEADERS ) #incldue <string> #endif

[matbech]

One sad thing I noticed with adding the .ixx file to a project. If you have a solution with 200 projects and all of them add the .ixx file then you compile the standard library module 200 times. This does only happen on the first build but :-( Hopefully MS will tell us a better way than this so that you only build it once per solution

I believe using a static library (add the std.ixx) which is then referenced by the other projects in your solution is the right approach.

For the mixed headers issue, I hope Stephan T. Lavavej (@StephanTLavavej) can provide some guidance.

[StephanTLavavej]

Thanks for trying to use the Standard Library Modules as soon as possible! 😻

We're still working on adding build system support so import std; will work automatically. (I believe I'll need to set an environment variable indicating where the modules directory is, and add a JSON file indicating how std.compat depends on std.) My apologies for not getting to this yet - it was important to merge the library and test code as early as possible to prevent regressions from ongoing compiler work, but then I got busy with other tasks (e.g. the big /clr PR #3194). At this point, I'm not sure if we can add build system support in time for the production release of VS 2022 17.5, but I hope everything will be ready for VS 2022 17.6 (at which point the compiler should also be working much more robustly).

Answering specific questions/topics (please let me know if I missed anything; thanks Igor Zhukov (@fsb4000) for quoting an earlier reply of mine from Discord):

• The /experimental:module compiler option and the "C++ Modules for v143 build tools (x64/x86 - experimental)" VS installer component are not needed for the C++23 Standard modules.
• Mixing #include <meow> and import std; in any order should work, according to the Standard. However, this is an extremely stressful scenario for the compiler (as it involves noticing that the classic header and the named module are providing the same machinery, and that they should be considered identical instead of duplicate definitions). I've been told by our modules dev Cameron DaCamara (@cdacamar) to expect that this will totally fail until major compiler work happens, so I have not added any test coverage for this scenario.
  • This is indeed a headache for migrating large codebases with third-party libraries. I don't have any further suggestions, other than my sympathies - the compiler team is aware that this scenario is important and they're working towards it, but it's going to take a while.
• Until automatic build system support is added, you are responsible for building std.ixx into std.ifc and std.obj. Note that, as long as the command lines match, you can build it once, and then consume it from a hundred projects. Centralizing this depends on what build system you are using, but there should be no fundamental challenge to making this work. Arranging for a static library to be produced seems reasonable. (You can build both std.ifc and std.compat.ifc, and create a .lib containing std.obj and the near-empty std.compat.obj, so that projects can consume either import std; or import std.compat; as they see fit.)
• Unlike the experimental modules, we are intentionally not distributing prebuilt IFCs/OBJs for the Standard modules, and have no plans to ever do so. Although this requires build systems to do a bit more work, it means that the Standard modules will fully respect all compiler options (release/debug, static/dynamic, Standard modes in the future, warning suppressions, re-enabling removed machinery, etc.).

[davidhunter22]

I have a work around for including third party libraries that then do old style #includes of standard library headers. If you have the tiniest shred of dignity you may want to look away now.

So the MS standard library headers still use old style macro include guards not #pragma once. So you can simply define all these macro guards yourself and then include the header file that does things like "#include ". Attached is a header that defines all the ones I think you need. Oddly you can't upload .h files so I renamed it to .txt

MacroGuards.txt

[matbech]

I have a work around for including third party libraries that then do old style #includes of standard library headers. If you have the tiniest shred of dignity you may want to look away now.

So the MS standard library headers still use old style macro include guards not #pragma once. So you can simply define all these macro guards yourself and then include the header file that does things like "#include ". Attached is a header that defines all the ones I think you need. Oddly you can't upload .h files so I renamed it to .txt

MacroGuards.txt

This does not work at all. If you define the guards then any C++ headers won't get included and the 3rd party headers which require those will not compile. E.g.

#include "MacroGuards.h"
#include <atlbase.h>

atlbase.h includes <type_traits> which won't get included because of the define in MacroGuards.h.

[davidhunter22]

I am including the headers in my code which has an "import std;" so all the standard library types are aready declared before I include the third party header. I should have mentioned you need to do

import std;
#include "MacroGuards.h"
#include <atlbase.h>

I am already using this successfully for a number of libraries, such as type_safe, pugxml and catch2 that I use via vcpkg without modfiying them in any way.
Sometimes the third party header you include assumes some things are in the global namespace like uint8_t. I also add a using std::uint8_t before I do the include to fix those. You could also "import std.compat" but I am keen to avoid that as not getting all the legacy junk is one of the reasons I am doing this.

[matbech]

It doesn't work for me when importing the std module in a precompiled header (e.g. pch.h) and I do include the 3rd party libraries there.