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,506 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,426 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,506 Reputation points Microsoft Vendor

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

Hope you've been well. Any updates about this issue?
CDev-8220 220 Reputation points

2025-01-08T20:58:11.2066667+00:00

Sorry for the delay.

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.

Yes, I am using x64 Native Tool Command Prompt, and in Visual Studio, the architecture is 64 bit.

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.

Yes, I realize I was getting compatibility issues, and I fixed those.

cl /W4 /EHsc /std:c++20 /O2 /GA /MD /fp:precise /sdl...

When I work on a project from the command-line, I am able to create the header unit (HeadersBase.h.ifc), and the module file (ModuleBase.ixx.ifc), which imports the header unit - import "HeadersBase.h";

I can then run this command :

cl ... /headerUnit:quote HeadersBase.h=HeadersBase.h.ifc /reference ModuleBase=ModuleBase.ixx.ifc TestModules.cpp

The import "HeadersBase.h"; seems to work, but import ModuleBase; does not work.

The program also does not run.

When I create a project in Visual Studio, and try importing either the header unit, or the module, I am still getting these errors:

Error (active) E3343 command-line error: no mapping specified for Test Warning C5210 'HeadersBase.h.ifc' is not a valid header unit reference; ignoring

However, these are the only errors at the moment.

This means that there will potentially be several ifc files, one for each platform:configuration pairs. This is annoying but expected.

I only get .ifc and .ifcast.
Minxin Yu 12,506 Reputation points Microsoft Vendor

2025-01-09T03:12:29.8933333+00:00

Is the project in release mode?
CDev-8220 220 Reputation points

2025-01-09T09:04:02.16+00:00

Yes, but I get the same error in both Release and Debug mode.
Minxin Yu 12,506 Reputation points Microsoft Vendor

2025-01-10T02:39:17.9533333+00:00

Try removing additional cl commands.
Use x64 cl to build commands and set project in debug mode.
cl /std:c++20 /exportHeader /headerName:quote HeadersBase.h

/std:c++20 /headerUnit C:\Exports\HeadersBase.h=C:\Exports\HeadersBase.h.ifc /headerUnit:quote HeadersBase.h=C:\Exports\HeadersBase.h.ifc
Minxin Yu 12,506 Reputation points Microsoft Vendor

2025-01-10T03:16:43.14+00:00

In addition, import "HeadersBase.h" missing; .
There is spelling error: import ModuleBase; ModulesBase.
CDev-8220 220 Reputation points

2025-01-11T00:22:04.7166667+00:00

For Debug mode

Error (active) E3343 command-line error: no mapping specified for Test Warning C5210 '...\HeadersBase.h.ifc' is not a valid header unit reference; ignoring Test Warning C5050 Possible incompatible environment while importing module '': _DEBUG is defined in current command line and not in module command line Test

Command-line for the project looks like this:

/JMC /reference "C:...\Debug\ModuleBase.ixx.ifc" /permissive- /ifcOutput "x64\Debug" /GS /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"x64\Debug\vc143.pdb" /Zc:inline /fp:precise /D "_DEBUG" /D "_WINDOWS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd /std:c++20 /FC /Fa"x64\Debug" /EHsc /nologo /Fo"x64\Debug" /Fp"x64\Debug\Test.pch" /diagnostics:column /headerUnit "C:...\Debug\HeadersBase.h.ifc"

For Release mode

Error (active) E3343 command-line error: no mapping specified for Test Warning C5210 '...\HeadersBase.h.ifc' is not a valid header unit reference; ignoring Test Error C1004 unexpected end-of-file found Test Warning C5210 '...\HeadersBase.h.ifc' is not a valid header unit reference; ignoring Test

Command-line for the project looks like this:

/reference "C:...\Release\ModuleBase.ixx.ifc" /permissive- /ifcOutput "x64\Release" /GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc143.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_WINDOWS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /std:c++20 /FC /Fa"x64\Release" /EHsc /nologo /Fo"x64\Release" /Fp"x64\Release\Test.pch" /diagnostics:column /headerUnit "C:...\Release\HeadersBase.h.ifc"

The only switch I am using, which is different, is /GA optimize for Windows Application, but this should not cause a problem, should it?

Removing any of the others causes incompatibility issues, as the environment is different.

I think the problem might be solved, if we figure out why I am getting the error :

no mapping specified for file.

Do you know what is the reason for this error?
CDev-8220 220 Reputation points

2025-01-11T12:31:30.3166667+00:00

I just realized /ifcMap exists.

Let me try this and see what results I get.
CDev-8220 220 Reputation points

2025-01-11T13:50:44.6733333+00:00
This is getting really stressful.

After creating an ifcMap file:

# Using literal strings [[header-unit]] name = ['quote', 'HeadersBase.h'] ifc = 'C:\...\Debug\HeadersBase.h.ifc' # Using literal strings [[module]] name = 'ModuleBase' ifc = 'C:\...\Debug\ModuleBase.ixx.ifc'

I used /ifcMap mapfile.ifc in the command line, and get additional errors.

Error (active) E3343 command-line error: no mapping specified for Test Warning C5210 '...\HeadersBase.h.ifc' is not a valid header unit reference; ignoring Test Error C7684 module name 'ModuleBase' has an ambiguous resolution to IFC Test Error C1004 unexpected end-of-file found Test Error C7684 module name 'ModuleBase' has an ambiguous resolution to IFC Test Error C7661 header-name 'HeadersBase.h' has an ambiguous resolution to header 'HeadersBase.h' Test Error C7612 could not find header unit for 'HeadersBase.h' Test

I've spent days on this, and feel like I am getting nowhere.
CDev-8220 220 Reputation points

2025-01-11T14:34:06.6266667+00:00

Created a new project.

Placed the ifc files in the project.

Added these files to the project.

Added the files paths to the Additional Module and Header Unit paths.

Immediately the significant error showed up.

Error (active) E3343 command-line error: no mapping specified for 'HeadersBase.h.ifc'

So, this definitely is the issue, I need to solve.

Did I create the ifcMap file correctly, and name it correctly (ifcmap.ifc), or...?
Darran Rowe 1,426 Reputation points

2025-01-11T20:11:41.9466667+00:00

It is potentially something else.

I came across an interesting document on the ISO C++ site about building C++ modules in Visual Studio. This can be found here.

Anyway, the very last paragraph states.

"Currently, for a number of reasons which might or might not go away when ifc format is stabilized, C++ intellisense does not use modules created during build even when they exist – it always builds them on its own (and to different locations than the “read” build). So with the externally supplied modules it is critical that we are able to find module source as well as compilation options, module dependencies & includes and be able to re-compile them."

So I am wondering if this is a case of Visual Studio itself is complaining because it cannot create its own copy of HeadersBase.h.ifc.
CDev-8220 220 Reputation points

2025-01-12T16:51:32.8+00:00

with the externally supplied modules it is critical that we are able to find module source as well as compilation options, module dependencies & includes and be able to re-compile them

That's interesting.

However, I also tried sourcing from where VS creates associated files of the ifc files - namely, \x64\debug, and that did not make a difference, so what would you suggest?
Darran Rowe 1,426 Reputation points

2025-01-12T18:41:22.38+00:00

However, I also tried sourcing from where VS creates associated files of the ifc files - namely, \x64\debug, and that did not make a difference, so what would you suggest?

Even if Visual Studio was able to find the header file(s) that produced a header unit, it would still be missing a huge amount of information. That information comes in the form of the compiler options, including preprocessor directives, that created the header unit.

The documentation seems to recommend using a static library project to create the header units.

It is also fine that the walkthrough for creating the static library project is for the STL, since the steps that would be taken for any other set of header units would be the same. But this approach allows Visual Studio to obtain the compiler options that compiled the header unit from the project system itself.
CDev-8220 220 Reputation points

2025-01-12T23:32:35.2033333+00:00

Thanks. I will try that.

One question though... Since I want my module.ixx to import the header unit, and then have my main.cpp import the module, do you think I should also make the module.ixx a Static library (.lib), so that my main.cpp will have no issues finding it?
CDev-8220 220 Reputation points

2025-01-17T20:23:50.2866667+00:00

This method apparently works only with header units and a console project.

Or am I missing something.

I created both a header file .h, and a module file .ixx in the shared project.

The module file imports the header unit...

export module ModulesBase;

export void MyFunc() {}

import "HeadersBase.h";

using namespace std;

Or so it seems. I get warnings, but it builds.

The startup (main) project imports the header unit okay, and runs with this code:

import "HeadersBase.h";

using namespace std;

int main() {

cout << "test" << endl;

}

However, I get an error on wWinMain.

import "HeadersBase.h";

using namespace std;

// Global Variables:

HINSTANCE hInst; // current instance

int APIENTRY wWinMain(

_In_ HINSTANCE hInstance,

_In_opt_ HINSTANCE hPrevInstance,

_In_ LPWSTR lpCmdLine,

_In_ int nCmdShow

) {

UNREFERENCED_PARAMETER(hPrevInstance);

UNREFERENCED_PARAMETER(lpCmdLine);

cout << "test" << endl;

return 0;

}

Error (active) E0065 expected a ';'

Trying to import the module gives me

Error (active) E1504 internal error

Can I not use a Windows Desktop Application for this project, and do you have any recommendations on how to get the module to import and be imported?
Darran Rowe 1,426 Reputation points

2025-01-18T01:40:16.6666667+00:00

Here is a little hint. Errors starting with an E come from the intellisense compiler. Sometimes the intellisense compiler just doesn't work that well.

If the project is built with the Visual C++ compiler and it doesn't report any errors then it basically means the intellisense compiler was wrong.
CDev-8220 220 Reputation points

2025-01-18T12:53:50.91+00:00

Yes, that's correct.

Error (active) E0065 expected a ';'

Error (active) E1504 internal error

Build FAILED.

Is there any response you can give to my question?
Darran Rowe 1,426 Reputation points

2025-01-18T14:01:40.2+00:00

As an interesting side note. If I remove a single preprocessor definition.

So header units work perfectly fine, but Visual Studio can report errors that don't exist.
CDev-8220 220 Reputation points

2025-01-21T18:25:05.15+00:00

header units work perfectly fine

The header units work yes.

It's the module I am having problems with... which I find odd, since the MS Documentations all make it a simple matter of creating an .ixx file with code export module module-name;, and a source file .cpp with code import module-name;, and I get errors trying to import the module, and can't figure why the build fails.

I'll just have to forget modules for now, but I'll give it one more try before I quit.

Thanks for your patience.
Darran Rowe 1,426 Reputation points

2025-01-21T20:33:21.91+00:00
It wasn't obvious, but my module was importing the header unit without issues too.

The wrapped_get_message was exported from the module and was calling GetMessage from the Windows.h header unit generated from Windows.h.

export module test_module; import <Windows.h>; export BOOL wrapped_get_message(MSG &msg) { return GetMessageW(&msg, nullptr, 0, 0); }

I even went further and tried using the STL as header units and even using std.ixx and std.compat.ixx. Even more complex header units from the Windows SDK have all worked.

One thing that I have noticed. Occasionally, you need to clean the entire solution and then rebuild everything. Have you tried doing that?
CDev-8220 220 Reputation points

2025-01-23T21:22:14.56+00:00
I did a "bare-bones" project, and it works.

First, I create an empty project named FinalTest

// Module.ixx

export module Module; export void MyFunc() {}

// Source.cpp

import Module; int main() { }

That builds fine.

I then add a new empty project named Headerbase and change the type to Shared Library

// Header.h

#pragma once #include <SDKDDKVer.h> #include <windows.h> #include <stdlib.h>

// Modules.ixx

export module Modules; import "Header.h";

That builds with no problem.

I can also now use the Module.ixx file to import either the header unit or the module, from the shared library.

export module Module; export void MyFunc() {} //import "Header.h"; export import Modules;

I get no complaints there.

The problems start occurring when I add #include <iostream> to the Header.h file.

I get plenty warnings from the headers in the Windows Kits directory.

Ignoring those, I also add #include <string> and add this to Modules.ixx

export { std::string s = ""; int n = 6; void funcTest() { s = "the number is " + to_string(n); std:cout << s << std::endl; } }

Now I get

Error (active) E3496 could not open module file "...\debug\Module.ixx.ifc.isense.dt"

Oh boy.

Anyway, let me not bother you with that.

I think you helped greatly, and I see it can work... At least a Console App does.

However when I try using an Windows Desktop App,

int APIENTRY wWinMain( _In_ HINSTANCE hInstance, _In_opt_ HINSTANCE hPrevInstance, _In_ LPWSTR lpCmdLine, _In_ int nCmdShow ) { return 0; }

I get an error.

Error LNK2019 unresolved external symbol main referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)

It's looking for main.

This is a concern to me, because I really want to do a Windows Desktop Application.

Should I open this in a new issue?
Darran Rowe 1,426 Reputation points

2025-01-23T23:34:58.3466667+00:00
Are you using the correct project template?

The entrypoint the linker looks for fundamentally is based upon the linker's /SUBSYSTEM option. The two important values here are CONSOLE and WINDOWS. The CONSOLE subsystem is used for console applications, and the linker will look for main or wmain. The WINDOWS subsystem is used for GUI applications, and the linker will look for WinMain or wWinMain.

The defaults depend on what project template is used to create the project.

If "Empty Project" or "Console App" are selected, then the default linker setting will be set to /SUBSYSTEM:CONSOLE.

If "Windows Desktop Application" is selected, then the default linker setting will be set to /SUBSYSTEM:WINDOWS.

If the "Windows Desktop Wizard" is chosen, then the default will be based upon whether "Console Application" or "Desktop Application" is chosen. Again, "Console Application" will default to /SUBSYSTEM:CONSOLE and "Desktop Application" will default to /SUBSYSTEM:WINDOWS.

If you wish to change a project's subsystem, then this can be found in the linker properties.

By changing this to Windows, the linker will treat it as a GUI application. In this case, some care is needed with the preprocessor directives. Visual Studio will set some defaults based on the project template used.

This is what is defined for console applications. (Please note, this is for the Debug configuration, the Release configuration defines NDEBUG).

This is what is defined for GUI applications. The preprocessor directives don't matter for linking, but if the preprocessor is used to conditionally compile based on these directives, then it can change the code.

Also, for the STL headers, then consider using the modules supplied by Visual Studio itself.

The modules provided can be found in the Visual Studio install directory.

The modules provided allow:

import std; import std.compat;

If, for whatever reason, the standard modules are unavailable to use. Place the STL header units into a separate static library to the Windows header units.
Darran Rowe 1,426 Reputation points

2025-01-23T23:53:21.6833333+00:00
In addition to my previous response, as far as the code in funcTest is concerned, it is incorrect. So are you sure that the compiler wasn't outputting compiler errors?

export { std::string s = ""; int n = 6; void funcTest() { //to_string is in the std namespace, unless there is a using namespace std //or using std::to_string that isn't shown, this is an error. s = "the number is " + to_string(n); //There is a single colon between std and cout. The namespace scope is double //colon. This is an error if using namespace std or using std::cout isn't //declared in a location that isn't visible. //std: is seen as a label here. std:cout << s << std::endl; } }

When I make the same kinds of mistake in the module. The intellisense outputs 4 messages.

The two actual compiler errors, the error indicating that the module could not be found, and then a follow on error due to the module not being found. It isn't surprising for the module that the intellisense uses not existing if there is a compiler error.

Also, for the warnings when <iostream> is included. Could more information be provided on what they are? The exact contents of the header unit would be useful. I have /W4 set and I have tried including <iostream> in several different locations in my tests, and the header unit compiles cleanly.
CDev-8220 220 Reputation points

2025-01-24T18:50:37.25+00:00
Thanks a billion and one!

You have helped me so greatly. I really appreciate it.

I now understand how to build my Windows Desktop Application, from an Empty project. I'll try the wizard first, since that seems to allow me to start empty as well.

My headache is gone. :)

Yes, the function had some mistakes. Correcting those resulted in a successful build.

Build started... 1>------ Build started: Project: HeadersBase, Configuration: Debug x64 ------ 1>Scanning sources for module dependencies... 1>Modules.ixx 1>Header.h 1>iostream 1>string 1>cctype 1>xstring 1>istream 1>iosfwd 1>xmemory 1>xpolymorphic_allocator.h 1>__msvc_sanitizer_annotate_container.hpp 1>ostream 1>cstdio 1>cstring 1>cwchar 1>xstddef 1>cstdint 1>cstdlib 1>limits 1>new 1>xatomic.h 1>xutility 1>tuple 1>type_traits 1>utility 1>ios 1>initializer_list 1>cstddef 1>xtr1common 1>cfloat 1>climits 1>exception 1>__msvc_iter_core.hpp 1>compare 1>xlocnum 1>concepts 1>cmath 1>bit 1>iterator 1>streambuf 1>xiosbase 1>system_error 1>xlocale 1>cerrno 1>__msvc_system_error_abi.hpp 1>stdexcept 1>xcall_once.h 1>xerrc.h 1>atomic 1>memory 1>typeinfo 1>xfacet 1>xlocinfo 1>xthreads.h 1>xatomic_wait.h 1>__msvc_xlocinfo_types.hpp 1>clocale 1>xtimec.h 1>ctime 1>Compiling... 1>cctype 1>__msvc_sanitizer_annotate_container.hpp 1>cstring 1>cstdio 1>cstdint 1>cstdlib 1>xtr1common 1>cfloat 1>climits 1>cerrno 1>xcall_once.h 1>xerrc.h 1>xfacet 1>__msvc_xlocinfo_types.hpp 1>ctime 1>clocale 1>cwchar 1>cstddef 1>xtimec.h 1>initializer_list 1>xstddef 1>__msvc_system_error_abi.hpp 1>xthreads.h 1>iosfwd 1>limits 1>type_traits 1>xatomic.h 1>exception 1>concepts 1>bit 1>new 1>typeinfo 1>compare 1>xatomic_wait.h 1>atomic 1>utility 1>__msvc_iter_core.hpp 1>xutility 1>tuple 1>cmath 1>xmemory 1>iterator 1>xpolymorphic_allocator.h 1>xstring 1>memory 1>string 1>stdexcept 1>xlocinfo 1>system_error 1>xlocale 1>xiosbase 1>streambuf 1>xlocnum 1>ios 1>ostream 1>istream 1>iostream 1>Header.h 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'At': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(618,1): message : see previous definition of 'At' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'When': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(619,1): message : see previous definition of 'When' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(400,1): message : see previous definition of 'Outptr' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_result_maybenull': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(401,1): message : see previous definition of 'Outptr_result_maybenull' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_opt': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(402,1): message : see previous definition of 'Outptr_opt' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_opt_result_maybenull': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(403,1): message : see previous definition of 'Outptr_opt_result_maybenull' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_result_z': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(404,1): message : see previous definition of 'Outptr_result_z' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_opt_result_z': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(405,1): message : see previous definition of 'Outptr_opt_result_z' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_result_maybenull_z': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(406,1): message : see previous definition of 'Outptr_result_maybenull_z' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_opt_result_maybenull_z': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(407,1): message : see previous definition of 'Outptr_opt_result_maybenull_z' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_result_nullonfailure': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(408,1): message : see previous definition of 'Outptr_result_nullonfailure' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'Outptr_opt_result_nullonfailure': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(409,1): message : see previous definition of 'Outptr_opt_result_nullonfailure' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: 'COM_Outptr': macro redefinition

I had to shorten it, so that it could post.

1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(631,1): message : see previous definition of '__blocksOn' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: '__control_entrypoint': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(844,1): message : see previous definition of '__control_entrypoint' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: '__data_entrypoint': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(1112,1): message : see previous definition of '__data_entrypoint' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: '__fallthrough': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(632,1): message : see previous definition of '__fallthrough' 1>C:\vsProjects\FinalTest\HeadersBase\Header.h(16,1): warning C4005: '__analysis_assume': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\shared\specstrings_strict.h(933,1): message : see previous definition of '__analysis_assume' 1>Modules.ixx 1>HeadersBase.vcxproj -> C:\vsProjects\FinalTest\x64\Debug\HeadersBase.lib 1>Done building project "HeadersBase.vcxproj". 2>------ Build started: Project: FinalTest, Configuration: Debug x64 ------ 2>Scanning sources for module dependencies... 2>Module.ixx 2>Compiling... 2>Module.ixx 2>Source.cpp 2>FinalTest.vcxproj -> C:\vsProjects\FinalTest\x64\Debug\FinalTest.exe ========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== ========== Build started at 2:02 PM and took 03:36.265 minutes ==========

I notice the warnings has to to with redefinitions.

Here is my header file:

#pragma once #include <SDKDDKVer.h> // Exclude rarely-used stuff from Windows headers #define WIN32_LEAN_AND_MEAN // Windows Header Files #include <windows.h> // C RunTime Header Files #include <stdlib.h> #include <malloc.h> #include <memory.h> #include <tchar.h> #include <string> #include <iostream>
Darran Rowe 1,426 Reputation points

2025-01-24T21:05:47.9966667+00:00

Is /translateInclude enabled on any of the projects? It isn't useful when using this method to create header units from header files and I think it just causes more problems.
CDev-8220 220 Reputation points

2025-01-25T13:01:43.96+00:00

That solved the problem, yes.

Thanks so much. You solved all the issues I have been having, and I am really happy now that I can use header units and modules, and have a better understanding.

This method also saves me time, since I can use these in any new projects I create.

Thank you.

Share via

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

Your answer