C++ module readiness

[mediabuff]

As new and modern header only library, what is the direction and thinking behind modules support ? Efforts like cppwirt seem to have been designed for modules . All the more critical if this is going to be the modern header replacement for Windows . Little skeptical here as the project is replete with macros

[dunhor]

I'm not entirely sure if the topic has come up before, but if it has, I doubt anything significant came out of it. The TL;DR is that until we have full compiler support to test out, I can't really say much to it.

I haven't really kept up with the changes made to modules since a few years ago, but from what I can gather, most of it should be pretty simple to do. E.g. seems like the following should get you most of the way there

// wil.cpp
export module wil;
export import <wil/com.h>;
export import <wil/filesystem.h>;
export import <wil/result_macros.h>; // Effectively meaningless...
// ...

// main.cpp
import wil;

int main() // ...

Or similarly, it seems you can just do this in your normal cpp files (which has the benefit of preserving macros):

// main.cpp
import <wil/com.h>;
import <wil/result_macros.h>; // Okay; macros are available for use

int main() // ...

I tried to test it out, but can't seem to get header units to work with Clang (no support in MSVC yet), but AFAIK this should work. I'm not entirely sure how configuration macros come in to play (e.g. RESULT_SUPPRESS_DEBUG_INFO, RESULT_SUPPRESS_STATIC_INITIALIZERS, etc.). I'd assume that definitions passed on the command line via -D... are preserved, but I'm not sure on that (I also wouldn't be surprised if it's an implementation detail of the compiler).

The resource.h header is the obvious odd one out. Ideally you'd be able to do something like:

module;
#include <windows.h>
// ... Other includes to "turn on" features of resource.h
#include <wil/resource.h>

export module wil;
export import <wil/com.h>;
// ... Export other WIL headers

export using namespace wil; // Error; not supported in C++20

But sadly I can't find a way to do something equivalent. That one will probably remain awkward and required to be included.

[mediabuff]

Thanks for your response . Msvc seems to be getting there. Please note the work in cppwinrt -
microsoft/cppwinrt#495 (comment)
So may make sense to be ready for this - in case some design changes need to be made for wil.

[dunhor]

WIL predates modules; if not entirely, it certainly predates modules being in a mature state. Its inception was ~2014 (but don't quote me on that). In addition, WIL's usage is prevalent - searching for "#include <wil" yields >20k hits in the OS repo alone - so being proactive with design decisions isn't as viable an option as one would hope. There are some things that could likely be made better while still maintaining compat, but until C++20 is signed off and compiler support catches up, it's probably best to just wait for now.

[sylveon]

For resource.h, it might just be possible to make modules per header, so a module for WinUser.h for example could be named wil.resource.WinUser.

[dunhor]

Looking more closely at the C++/WinRT change, it does something interesting that might work out. E.g. we could have something like:

module;
#include <windows.h>
// ... Other includes or defines to control features/behaviors

export module wil;
#define WIL_EXPORT export
#include <wil/resource.h>
// ...

And then we could just define WIL_EXPORT to nothing in common.h (or wistd_config.h) and use WIL_EXPORT throughout, either on namespace (the "safe" approach, but would include everything in the wil::details namespace) or on each function/class definition (but error prone). I'm unsure if this could easily lead to multiple definition errors if someone later includes one of the headers (I could see this not having the same level support as import <>), which might be troublesome, especially since this scheme wouldn't work for the result_macros.h header meaning consumers would still need to #include/import <> the header.

This also of course puts the burden on the consumer - it would be them who authors this file - but I'm not convinced that's not the better option anyway.

[mediabuff]

any update ? vc++ has progressed much on modules implementation.

[Arthapz]

tried to use it as header unit but doesn't work either :D

module;

#define __SPECSTRINGS_STRICT_LEVEL 0
#include <windows.h>

export module stormkit.Core:DynamicLoaderImpl;

import :Expected;
import :Types;

// clang-format off
import <wil/win32_helpers.h>;
// clang-format on

[  8%]: compiling.headerunit.debug win32_helpers.h
C:\Program Files (x86)\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\bin\HostX64\x64\cl.exe -nologo -Zi -FS -Fd..\..\build\debug\stormkit\windows\x64\debug\stormkit-core.pdb -fp:fast -O2 -fp:fast -arch:AVX -arch:AVX2 -std:c++latest -MDd -Icore\include -I..\..\build\debug\stormkit\include -Istd-modules\modules -D_CRT_SECURE_NO_WARNINGS -DSTORMKIT_BUILD -DSTORMKIT_BUILD_DEBUG -DSTORMKIT_ASSERT=1 -DSTORMKIT_STATIC -DGLM_FORCE_RADIANS -DGLM_FORCE_DEPTH_ZERO_TO_ONE -DNOMINMAX -DWIN32_LEAN_AND_MEAN /EHsc -external:W0 -external:IC:\Users\arthu\AppData\Local\.xmake\packages\g\glm\0.9.9+8\00c2081c17c64d23ad0bf9034abc0eb8\include -external:W0 -external:IC:\Users\arthu\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include /utf-8 /bigobj /permissive- /Zc:wchar_t /Zc:__cplusplus /Zc:externConstexpr /Zc:inline /Zc:lambda /Zc:preprocessor /Zc:referenceBinding /Zc:strictStrings /Zc:throwingNew -experimental:module /wd4251 /wd4297 /wd5063 /wd5260 /wd5050 /wd4005 /wd4611 -TP -c -exportHeader -headerName:angle C:\Users\arthu\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include\wil\win32_helpers.h -ifcOutput ..\..\build\debug\stormkit\.gens\stormkit-core\windows\x64\debug\rules\modules\cache\Users\arthu\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include\wil /Fo..\..\build\debug\stormkit\.objs\stormkit-core\windows\x64\debug\__\__\__\__\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include\wil\win32_helpers.h.obj
win32_helpers.h
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winnt.h(169): fatal error C1189: #error:  "No Target Architecture"
error: @programdir\modules\private\async\runjobs.lua:256: @programdir\core\sandbox\modules\os.lua:372: execv(C:\Program Files (x86)\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.35.32124\bin\HostX64\x64\cl.exe -nologo -Zi -FS -Fd..\..\build\debug\stormkit\windows\x64\debug\stormkit-core.pdb -fp:fast -O2 -fp:fast -arch:AVX -arch:AVX2 -std:c++latest -MDd -Icore\include -I..\..\build\debug\stormkit\include -Istd-modules\modules -D_CRT_SECURE_NO_WARNINGS -DSTORMKIT_BUILD -DSTORMKIT_BUILD_DEBUG -DSTORMKIT_ASSERT=1 -DSTORMKIT_STATIC -DGLM_FORCE_RADIANS -DGLM_FORCE_DEPTH_ZERO_TO_ONE -DNOMINMAX -DWIN32_LEAN_AND_MEAN /EHsc -external:W0 -external:IC:\Users\arthu\AppData\Local\.xmake\packages\g\glm\0.9.9+8\00c2081c17c64d23ad0bf9034abc0eb8\include -external:W0 -external:IC:\Users\arthu\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include /utf-8 /bigobj /permissive- /Zc:wchar_t /Zc:__cplusplus /Zc:externConstexpr /Zc:inline /Zc:lambda /Zc:preprocessor /Zc:referenceBinding /Zc:strictStrings /Zc:throwingNew -experimental:module /wd4251 /wd4297 /wd5063 /wd5260 /wd5050 /wd4005 /wd4611 -TP -c -exportHeader -headerName:angle C:\Users\arthu\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include\wil\win32_helpers.h -ifcOutput ..\..\build\debug\stormkit\.gens\stormkit-core\windows\x64\debug\rules\modules\cache\Users\arthu\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include\wil /Fo..\..\build\debug\stormkit\.objs\stormkit-core\windows\x64\debug\__\__\__\__\AppData\Local\.xmake\packages\w\wil\2022.09.16\15599889dd0045eab49f111d1983d804\include\wil\win32_helpers.h.obj) failed(2)

[sharadhr]

Is it time to resurrect this issue? MSVC and Clang both have massively improved their C++ named module support.

I'd like to contribute a named module in the style of what has been done with Vulkan-Hpp: include all the headers in a single module interface file containing export module wil;, set up a 'we are in the module' macro (for instance, WIL_CPP_MODULE), and then set up a WIL_EXPORT macro that depends on that macro, and then annotate everything that needs to be exported (this will be the most time-consuming bit, and probably cannot be easily automated nor LLMed).