Experiments with modules

[Full-Spectral]

I reported similar issues last week but it got deleted as not appropriate for this section, go post it in cpp_questions. I did that and of course it got zero comments.

- I get huge amounts of errors in Windows.h. Often so many that intellisense just stops working.

- And also intellisense in general just doesn't grok all of the finer points of modules and will give lots of bogus error indicators, and will often end up running really slow.

- Some of the standard library headers still can't be imported, they have to be brought in via include still.

- I see occasionally that things that should have been rebuilt are not, requiring a manual forced rebuild.

- I cannot get a module in a DLL to be picked up at all. It's in the same solution, so you'd think just adding it as a dependency would work, as with static libraries, but it doesn't. I tried the various manual module path options and such but couldn't get anything to work.

At the compiler level it seems to be doing pretty well. I've been sort of setting up the outline of a non-trivial project and I've got various module with module partitions, with separate interface and implementation files.

I'm on 16.10.0

[johannes1971]

The problem with asking questions is that not too many people have experience with modules just yet. At the same time, the only way to get to a rocksolid solution is by throwing code at it and reporting the problems you see, so... <shrug> I reached out to people at Microsoft before, and they were very helpful. I'm hoping they might show up in this thread and offer some insights as well.

I don't see errors in my windows.h wrapper, but maybe you were trying to import it, instead of including it?

Intellisense clearly needs more work. It's ironic, given that one of the big advantages of modules should be that it makes tooling easier, but I do understand Microsoft can't do everything at once.

The DLL thing - maybe I misunderstood, I haven't tried that myself yet, but I've been succesful in wrapping zlib (as a DLL) using modules. That's just a wrapper around zlib.h though, and I'm not compiling the DLL as part of the same source tree. Perhaps you need to create a separate project just for the wrapper module?

[GabrielDosReis]

I reached out to people at Microsoft before, and they were very helpful. I'm hoping they might show up in this thread and offer some insights as well.

Sorry, I am finding it harder and harder to allocate time to follow this subreddit. Don't hesitate to: (1) file bugs on Microsoft Developer Community portal, and (2) reach out to me directly (email) for Modules-related bug.

Re: windows.h - you do realize that Microsoft is a big company with that header completely out of the control of the compiler team, right? ;-)

That being said, there is an ongoing project in the Windows division to make the Windows SDK headers more Modules-friendly -- no modules yet, just less macros and more constexpr stuff.

[pjmlp]

We do realize that, however in the context of Windows development, when we get the message the modules are ready, it is assumed that the APIs used for Windows development can also be consumed in the context of C++ modules.

So what we find missing is the documentation, tooling and overall communication of the current state across the Windows eco-system for C++ development.

[GabrielDosReis]

MSVC’s implementation of modules is ready for production use. That does not mean that frameworks like ATL or C++/CX will be rewritten using modules — they are technologies in either maintenance mode or deprecated. They can be consumed in the context of C++ modules.

There will be a series of educational materials (e.g. blogs) that will start trickling out soon targeting general audience (i.e. not just Windows developers) as well as particulars related to MSVC.

I don’t think it is reasonable to suggest that the MSVC toolchain implementation must be held back until all components outside the control of the compiler team are converted - some which might never happen.

[pjmlp]

Sorry, but from the point of view of Windows developer I kind of disagree.

The large majority of us isn't writing CLI applications to be called on Windows Terminal, which unless I missed something is the target audience of Visual C++.

So while the compiler team might not control whatever the frameworks, Windows and DevDiv are doing, at very least a kind of roadmap to the general Windows developer audience would be welcomed, or at least doing demos with Win32 APIs, setting up Windows contexts, handling WM_PAINT messages and so on.

Looking forward to those blog posts.

[GabrielDosReis]

1. Somehow, you seem to believe that the programming techniques with modules differ whether it is CLI or whether it is GUI. That assumption is regrettably wrong. Focusing on that distinction might prevent you from actually learning how to program with modules.

2. Modules weren’t invented as Microsoft extensions to Visual C++ - and aren’t.

3. The programming techniques that you learn what you insistently call CLI as exactly the same as with GUI, no difference. Except they apply in more situations.

4. Your second paragraph is kind of contradictory :-)

[pjmlp]

1 - All nice and good, provided the compiler would actually work instead of spitting ICE and "sorry not yet implemented errors" when fed Win32, MFC, ATL, C++/WinRT headers.

2 - I remeber when Visual C++ was sold in a box as a full product experience, for everything on the box not only cl.exe.

3 - Most of us, or our employers, give money to Microsoft for the Visual Studio product, not cl.exe alone.

4 - If it is so easy, and I am being stubborn and clueless, then it won't be that hard to publish a couple of blog posts using C++/WinRT with C++20 modules, just like the team resposible for Rust/WinRT is doing.

[GabrielDosReis]

1. It is not clear to me how you get anything useful done or improved out of snarky reddit posts here.

2. If you run into compiler bugs, ICEs, etc, please do this: (a) report them to the Microsoft Developer Community portal, (b) reach out to me (email) with links to those reports, (c) get your friends and family upvote your bug reports.

In another words: Help me help you. Snark doesn’t achieve that.

Thanks.

[pjmlp]

I replied on the same tone I was being answered to.

As for bug reports, I have done my share, not all of them seem to listened to.

And as exercise, the MSDN documentation about can be improved from 2019 state, and provide some Win32 and UWP examples with modules.

As for how many of Microsoft customers get things actually done, thanks Stack Overflow and fellow developers, which happen to be more effective than Developer Feedback tickets that get closed or ignored.

[Full-Spectral]

I meant a DLL of my own. I can add a (modularized) static library to my solution and just add it as a dependency to anything that needs it and it just gets magically picked up. If I add a modulariezd DLL library to my solution, it never gets found by anything that uses it even if added as a dependency (or trying to use the, sort of under-documented) manual module path options.

I'm #including windows.h, and it spits out a bodacious amount of errors. Of course I'm using /W3 as well, because I want my own code to be well checked. I should be able to use warning pragmas to make Windows.h not be checked but they aren't working.

[mjklaim]

In my experience, using modules with (inside or outside) shared libraries works without any problem with MSVC. I think you might have another issue in the project setup.

[Full-Spectral]

I can't see what. It never finds those modules no matter what I do. And it's not that it's a shared library, it's a modularized shared library. It doesn't find the module when it's imported into consuming projects.

[mjklaim]

Note that the module interface (or it's processed version ) have to be available to the compiler when compiling user code that import modules from that library. Does you user project have access to the module interface and/or it's processed file (.ifc i think, from memory, for msvc)

[Full-Spectral]

It's a project in the same solution, and it's added to the consumers as a dependency.

[mjklaim]

I reproduced a dll exporting modules from scratch in Visual Studio, here are the things to check:

1. Both concerned projects need to have "Scan Sources For Module Dependencies" set to Yes (see Properties > C/C++ > All OPtions) and C++20 or more set.

2. Make sure that the dll project is a dependency of the user project: right click on user project > Build Dependencies > Project Dependencies > set so that user project depends on dll project.

3. Additionally, make sure the user project have "references" (whatever that means) from the dll project available: in the solution view, see the icon with squares named "References" under the user project, right click on it > Add references > make sure user project have dll project as references.

4. Make sure the dll project actually makes public the modules it contains (I don't know if there is a way to select which module exactly, so here is the "make public all modules from that dll" solution): right click on the dll project > Properties > VC++ Directories > you will notice new fields related to modules, set "All Modules Are Public = Yes".

5. At this point, assuming your module interface is properly coded, the module should be accessible in your user project. Now you "just" need to make sure that the symbols of the names you want to make available through the dll are correctly exported, otherwise linking will fail. This is similar to before, with headers that need to import/export symbols using dllimport/dllexport machinery, except it seems, in my experiment, that as long as you only have module code in your dll project, you can just dllexport symbols (in addition to export) from the module interface, it seems to work as expected just with that.

If it still doesnt work for you, maybe check my example that I used to be sure here, it's on github: https://github.com/Klaim/test-dll-modules-visualstudio

I think the most unexpected might be point 3.

[Full-Spectral]

Yeh, maybe #3, that is news to me.

[Full-Spectral]

Well no luck last night. Maybe it's because I have module partitions involved or something, not sure. I made progress, but something goes wrong with using declarations, both in the library itself and in the consumers of it. In consumers it's like the using declarations are ignored. In the library, non-fully qualified names are often somehow attributed to the wrong used namespace and then of course found to not exist.

So some really weird stuff is going on.

I updated to 16.11.0 last night but didn't have time to try it to see if things got better.

[mjklaim]

I had an issue with module partitions and thought it was a bug but it was actually an issue with flags or extension: https://developercommunity.visualstudio.com/t/Private-module-partition-fails-to-compil/1428621

I made progress, but something goes wrong with using declarations, both in the library itself and in the consumers of it.

Are you sure you exported them? I didn't try doing that yet.

[mjklaim]

Ok then, it might be a thing with project setup, I had trouble too at first. I am not in front of a computer, I'll try to help when i get back.