Why do I have problems when trying to import a header unit?

CDev-8220 220

I used VS Developer PowerShell to create a header unit file from a header file.

cl /std:c++20 /exportHeader /headerName:quote HeadersBase.h

Not sure if that was the right thing to do.

Then I created an empty project to see if I can import the header unit successfully.

// ModulesBase.ixx

export module ModulesBase; // command-line error: no mapping specified for C:/Exports/HeadersBase.h.ifc
import "HeadersBase.h"
using namespace std;
export void MyFunc() {}

In the properties of the Modulebase file, I used these in the command-line

/std:c++20 /headerUnit C:\Exports\HeadersBase.h=C:\Exports\HeadersBase.h.ifc /headerUnit:quote HeadersBase.h=C:\Exports\HeadersBase.h.ifc

When I build, I get errors

E3343 ommand-line error: no mapping specified for Test C:\Projects\Test\Test\ModulesBase.ixx 1 Warning C5210 'C:\Exports\HeadersBase.h.ifc' is not a valid header unit reference; ignoring Test C:\Projects\Test\Test\ModulesBase.ixx 1 Error C1083 Cannot open header unit file: 'HeadersBase.h': No such file or directory Test C:\Projects\Test\Test\ModulesBase.ixx 8 Warning MSB8074 Cannot read Module Dependencies file x64\Debug\ModulesBase.ixx.module.json: Expecting element 'root' from namespace ''.. Encountered 'None' with name '', namespace ''. The build order might be incorrect. Test C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets 486 Error C1190 System::Object not found, missing /clr option or missing import of standard assemblies? Test C:\Projects\Test\Test\ModulesBase.ixx 3

Minxin Yu 12,341 Reputation points Microsoft Vendor

2024-12-31T06:53:10.83+00:00

I cannot reproduce the problem. The error message you provided did not occur.
Build project successfully.
Darran Rowe 1,316 Reputation points

2024-12-31T19:49:38.39+00:00
If the command line stated is what was given, then there is potentially a massive difference in the command line and environment.

As I stated in my previous set of replies, the Windows headers are not well behaved. This means that macros will make a massive difference.

Now, as mentioned, the developer powershell was used to build. The big issue here is that the developer powershell defaults to the x86 compiler.

As I also previously stated, the Windows headers are two APIs in one. The Windows 32 bit API and the Windows 64 bit API. The x86 compiler defines the _M_IX86 macro automatically, and this is used in Windows.h to automatically tell the headers that it is in the Windows 32 bit API mode, and anything platform specific must be defined for x86.

//Taken from Windows.h version 26100 line 106 #if !defined(_68K_) && !defined(_MPPC_) && !defined(_X86_) && !defined(_IA64_) && !defined(_AMD64_) && !defined(_ARM_) && !defined(_ARM64_) && !defined(_ARM64EC_) && defined(_M_IX86) #define _X86_ #if !defined(_CHPE_X86_ARM64_) && defined(_M_HYBRID) #define _CHPE_X86_ARM64_ #endif #endif

There are also large blocks in the headers, especially winnt.h, that are conditionally compiler and protected by blocks based on the platform.

Now, the error message states

x64\Debug\ModulesBase.ixx.module.json

In other words, a header unit or module compiled targetting the 32 bit x86 release environment is being used in a 64 bit AMD64 debug build. THIS IS BAD!!!!!

I don't use bold and caps lightly here. Very basic definitions are completely different between the two different APIs. This means that in a 64 bit application, the 32 bit definitions will cause crashes due to pointer truncation and are very hard to diagnose.

Header units and modules should be thought of as precompiled headers and not as include files. The definitions are decided on when the header unit is compiled and not when the application is compiled. This means that when you use a badly behaving header file in a header unit, IT MUST MATCH THE PLATFORM THAT YOU WANT TO USE IT FOR.

I also apologise if the emphasis feels agressive.

Now, instead of writing a lot of what went wrong, here is really what should be done.

First, make sure that the compiler that is used matches the intended environment. So, if the application is built targetting x64, make sure that the header unit is built using the x64 compiler. Secondly, match as many of the command line options as possible from the target project. Command line options that name output files, like /Fo and /Fd don't need to match, but important ones like /O2 and /EHsc really should.

This means that there will potentially be several ifc files, one for each platform:configuration pairs. This is annoying but expected.
Minxin Yu 12,341 Reputation points Microsoft Vendor

2025-01-02T07:15:49.88+00:00

Hope you've been well. Any updates about this issue?

Share via

Why do I have problems when trying to import a header unit?

Your answer