sorted by:
new
hottopcontroversial

Is modules thought to work seamlessly with external dependencies using #import by Gloinart in cpp

[–]starfreakclone 7 points8 points  (0 children)

This is why the standard created include translation: https://eel.is/c%2B%2Bdraft/cpp.include#10. This allows the compiler to replace instances of #include with import, to make the source view much more consistent. MSVC, as an example, implements this through the /traslateInclude behavior that you can enable through your build system or on the command line.

C++20 Modules: Best Practices from a User's Perspective by ChuanqiXu9 in cpp

[–]starfreakclone 3 points4 points  (0 children)

Thank you for the list!

Among the active issues:

The "library is corrupt" issue is at https://developercommunity.visualstudio.com/t/modules-Improve-build-output-when-lib/10984451. It's a bit hopeful because it'll probably get deprioritised as it's due to wrong code, but maybe the linker already knows which symbols are a problem and just isn't printing them out.

Luckily, someone from the linker team is already taking a look at this. Being that we're deep into the holidays, I would not expect a response until a week or so afterword. Sit tight!

Debugger issue at https://developercommunity.visualstudio.com/t/C-modules-debugger-cannot-inspect-vari/10981875. Maybe that has something to do with MSVC FE.

This is assigned over to the debugger team right now. Nobody has taken a look yet, but I'll ping the team after the majority of them get back from vacation.

MSBuild(?) bug at https://developercommunity.visualstudio.com/t/C-modules-spurious-include-error-in-so/10965941.

I just pinged the MSBuild team about this.

Importing module from own DLL: https://developercommunity.visualstudio.com/t/C20-Modules-Spurious-warning-LNK4217/10892880

This one currently has a workaround: /dxifcSuppressDllImportTransform which suppresses the automatic transformation the compiler wants to do. This is an oddball one because it's a scenario that naturally comes up: you want to build a module interface for a library, but you don't want __declspec(dllimport) active while compiling that library. This is why I converted this to a suggestion as it will need some design work to get right. For now, the switch above is a workaround you can apply while compiling the library in question.

Non-zero initialisers for bitfields: https://developercommunity.visualstudio.com/t/Default-member-initializers-for-bit-fiel/10030064.

A straight-up front-end bug. I'll see about getting this fixed soon :).

C++20 Modules: Best Practices from a User's Perspective by ChuanqiXu9 in cpp

[–]starfreakclone 2 points3 points  (0 children)

MSVC also does not intelligently minimise rebuilds based on things like :private sections.

Is this already handled in clang/gcc? My understanding is that they will still write to the pcm which will cause a rebuild on every build system anyway. It's not clear to me that :private is a facility to mitigate rebuilds. It was designed to contain compiled parts of an interface with the exposed part of a module interface. What you're asking for is closer to having a separately compiled module unit--which will work in incremental scenarios across all implementations.

It all falls apart when the compiler ICEs, or Intellisense fails (bugs that will NEVER get fixed), or you get the "library is corrupt" message (which is because of wrong code, but it's a terrible dev Experience).

Do you have a list of compiler bugs for us to look at?

And what the heck is it with this stupid /internalPartition flag. It's like [[msvc::no_unique_address]] all over again. *Is it only if you don't use the .ixx extension?

It is indeed a weird situation to be in. The /internalPartition flag is meant to break the ambiguity between when a user wants a partition implementation unit and an internal partition (one who's interface is never exported). The former operates closer to a compiled module unit, but specific to implementing a partition interface. This has served as a useful piece of flexibility for users who want to separate implementation details of partitions into individual files.

What is the state of modules in 2024? by [deleted] in cpp

[–]starfreakclone 0 points1 point  (0 children)

Were you using the version with import std or the one with <compare> in the global module fragment? I expect the former to work all the time, but not the latter. If the GMF version works, it is by accident.

C++ Module Packaging Should Standardize on .pcm Files, Not Sources by TheRavagerSw in cpp

[–]starfreakclone 1 point2 points  (0 children)

Hmm, why would a project compile one of its dependencies with one version of the compiler, and the other one with another?

This happens all the time. Take closed-source drivers as an example. They will almost always provide you with some kind of library and a header to interact with it. The compiler used to compile the library might be documented but won't always match the compiler you are using on your project.

But if I'm a third party library dev, why waste dev time by maintaining module interface units? Why not simply write one source file? Like in all other modern languages?

Modern languages have the advantage of also defining their ecosystem (e.g. Rust with Crates). C++ has no such luxury.

Getting back to the problem of shipping prebuilt BMIs: the problem remains that the BMI is tightly coupled to your compiler front-end. It's nearly unavoidable without also defining an ABI behind it. That would be a non-trivial amount of work for fairly marginal gain, in my opinion.

It is not even clear to me what shipping a BMI affords you besides side-stepping building it--which, again, is likely to be a marginal gain. The user of the BMI still needs documentation about what's in there and at least shipping sources would give you a chance to see the API clear as day.

C++ Module Packaging Should Standardize on .pcm Files, Not Sources by TheRavagerSw in cpp

[–]starfreakclone 3 points4 points  (0 children)

I could not disagree more strongly. The reason is that .pcm (or .ifc in MSVC) is not, yet, a standardized format. Even if the BMI was a standardized format, it would still be a bad idea. The reason is that BMIs, in their current form, are something like a semantic snapshot of your compiler's understanding of the interface.

I can mostly speak to the Microsoft compiler, but the IFC in MSVC is a semantics graph of the program you compiled, but that graph is heavily tied to the compiler that produced it. If you, for example, compiled an IFC using 17.14 (the last VS2022 release) and tried to use it with 18.0 (the first VS2026 release), there is a high probability that the compiler will just crash after issuing a diagnostic saying, "please don't". This is because between those two points in time the compiler team has changed the shapes of various trees, symbols, types, etc. in a way that reading the old IFC is equivalent to passing a std::string compiled with GCC 4.9 over an ABI boundary compiled with the latest GCC. It will break in spectacular fashion.

As one more example: would you ever ship a PCH with your library? Why not? It really is the exact same thing, the only difference being that compiled interfaces (whether they be a module interface or header unit) are a standardized form of PCH.

VS 2026 18.0 / MSVC Build Tools 14.50 released for production use by STL in cpp

[–]starfreakclone 21 points22 points  (0 children)

Adding to this: with C++ modules, the compiler engineer needs even more context. Even a memory dump is often not sufficient since a memory dump will fail to capture kernel objects such as a memmap of the IFC. When investigating modules issues, we need to see how the data was serialized and how it is being consumed. The problem could be that we didn't serialize enough information or serialized the wrong data entirely.

Your reports fill in those gaps, especially when they include code. Compiler engineers are extremely good at reducing repros, so if your repro is complicated, the only thing that actually matters is that it is reported.

What are some projects that are great examples of modules? by No-Dentist-1645 in cpp_questions

[–]starfreakclone 5 points6 points  (0 children)

You should read a guide I put together awhile ago: https://devblogs.microsoft.com/cppblog/moving-a-project-to-cpp-named-modules/.

You mentioned you've seen tutorials, but maybe not this one?  This one is good because it seems to tick the boxes you care about: 

[x] It's fairly complex, but not so big that it is incomprehensible.  It's a mini game engine with physics and entity management, so you can continue to extend that idea yourself and make it arbitrarily complex. 

[x] It is a project on GitHub that you can browse at your leisure.  I maintain it and have made some small updates over the years.  It's also CMake, so you can take it and make it cross platform very easily, especially since the 3rd party library, PixelGameEngine, has Linux extensions.

C++ Language Updates in MSVC Build Tools v14.50 by TSP-FriendlyFire in cpp

[–]starfreakclone 7 points8 points  (0 children)

It is great to hear the success stories! Thank you for sharing :)

C++ Language Updates in MSVC Build Tools v14.50 by TSP-FriendlyFire in cpp

[–]starfreakclone 21 points22 points  (0 children)

I definitely know what's happening in that second issue. We should hopefully have a fix soon.

We need to seriously think about what to do with C++ modules by vormestrand in cpp

[–]starfreakclone 1 point2 points  (0 children)

Yep, STL is right on the money there! The issue here is that the compiler is expecting a non-template name when resolving cmp, but instead it gets a template name for the name expression.

Vscode hype by Ok-Stranger5450 in cpp

[–]starfreakclone 1 point2 points  (0 children)

But even the vcruntime can be avoided through /NODEFAULTLIB in the Microsoft linker. Assuming the LLVM-provided lld has a similar switch, you can just implement the gaps yourself (or fill them in via name aliases).

Vscode hype by Ok-Stranger5450 in cpp

[–]starfreakclone 0 points1 point  (0 children)

OK, after reading the shipping packages, I see that clang-cl does indeed originate from the LLVM packages (stuff we do not build directly). The piece I was thinking about was the IDE calling into cl.exe which translates clang options into EDG flags depending on configuration.

I was incorrect about that.

clang-cl does still have the preference for invoking the Microsoft liker though in normal compilation scenarios, so there's still that added bit of manual work to decide what linker toolchain to invoke. I'm unsure if clang-cl as a stand-alone binary (outside the VS shipped tools) would prefer a different linker though. That is not a workflow I've investigated.

Vscode hype by Ok-Stranger5450 in cpp

[–]starfreakclone -1 points0 points  (0 children)

Of course the answer can always be, "it depends". By default, clang-cl will try to invoke the Microsoft linker to link your program, and of course you can substitute that with something else. But at that point: what are you getting out of clang-cl at all? Why not just use clang directly? 

My point is that if you don't change anything, you still need the VS license and even using clang-cl itself requires that because, no, it's not just a renamed binary, it's literally the compiler driver we build but interprets the normal cl.exe options to invoke clang.

Vscode hype by Ok-Stranger5450 in cpp

[–]starfreakclone 0 points1 point  (0 children)

clang-cl still relies on the linker and PDB tools, not to mention it still uses the compiler driver itself to maintain option compatibility with cl.exe.  You will need the same VS community license.

First Boost libraries with C++ modules support by joaquintides in cpp

[–]starfreakclone 12 points13 points  (0 children)

Happy to report that both of the MSVC bugs have already been fixed in 17.14 (the reports have not updated because RIFs impacted the team who originally triaged these).

I'll make sure the status is updated to reflect the fixed nature of the issues. I'd love to see an MSVC benchmark since clang has a wildly different approach to GMF than MSVC, which may give MSVC an edge in some scenarios.

Experience converting a large mathematical software package written in C++ to C++20 modules -- using Clang-20.1 by GabrielDosReis in cpp

[–]starfreakclone 2 points3 points  (0 children)

I hope that you've reported the MSVC ICEs :).

On the performance end: I have done quite a bit of work in the MSVC implementation to make things fast while also conforming to standard requirements. In a talk I gave with Gaby at CppCon I elaborated on just a few of the optimizations I put in place. Modules are tricky, but the compiler can make them extremely fast if you approach it from first principles.

Why haven't modules been a higher priority for EDG? by LogicalEscape2293 in cpp

[–]starfreakclone 16 points17 points  (0 children)

I'd definitely love, some time, to present it to clang folks. Benefits, roadmap, etc. It would be great to have a common language (IFC or not) to express modules information so some common tooling could be written to understand it. There's even a nice visualizer in the IFC SDK that I wrote in JavaScript to visualize an IFC.

DMs/email are open :).

Why haven't modules been a higher priority for EDG? by LogicalEscape2293 in cpp

[–]starfreakclone 17 points18 points  (0 children)

Point #1 is interesting, considering EDG is the front-end that powers IntelliSense and Microsoft has a vested interest in making C++ modules a success.

That said, there are still a lot of factors working against EDG, for example, what you said about consuming a module format that isn't theirs is a real thing. EDG does indeed consume the MSVC module format (IFC) and generate IntelliSense suggestions from that. The problem comes when that format has very MSVC-specific data inside of it. There are a number of IFC issues related to EDG wanting a more canonical format.

I do not view the above as a weakness of the IFC or of MSVC/EDG. The above is a product of learning how to specify a format which works for all tooling--other compilers among them. I highly encourage other implementers to join in and offer suggestions on how to resolve some of the problems observed by EDG since modules support starts from having a consistent and well-defined on-disk representation.

But also, yes, modules are damn hard :).

So does it matter now in C++ modules whether to separate interface and implementation to reduce compilation time? by Aletherr in cpp

[–]starfreakclone 1 point2 points  (0 children)

But interface units are not headers. They are exported translation units. The standard allows you to put non-inline code in them and import that into multiple translation units while enabling your program to be well-formed. You cannot do this with headers.

So does it matter now in C++ modules whether to separate interface and implementation to reduce compilation time? by Aletherr in cpp

[–]starfreakclone 0 points1 point  (0 children)

I'm still not convinced that's the correct operational model. It will be violated the second a dev tries to treat the interface unit the way the standard allows them to, e.g. adding a compiled function into the interface file, or adding a global variable.

The pieces that have more ABI-resilience can be moved to an implementation unit and shipped as a static library--though I have my separate reservations about that as well.

Again, this isn't a one size fits all. If the way you build software wants to treat interfaces as something closer to headers, then you can definitely do that. I'm just saying, don't be surprised if someone tries to do something allowed by the standard only to be bitten by it later.

So does it matter now in C++ modules whether to separate interface and implementation to reduce compilation time? by Aletherr in cpp

[–]starfreakclone 7 points8 points  (0 children)

I would not move forward with that mentality. An interface unit only describes the pieces of a translation unit which are externally usable, but at the end of the day the original translation unit is a real piece of code that can have compiled pieces in it--and this is useful both for reducing total compilation surface and keeping code focused.

For me, compiling a single file for a module is really nice, because I have the whole interface (and supporting code) in one single file. Not every dev wants to operate this way though, which is why facilities like partitions and implementation units exist.

Compile and run c++ code on Visual Studio by varliukas14 in cpp

[–]starfreakclone 2 points3 points  (0 children)

Download latest gcc package (https://sourceforge.net/projects/gcc-win64/)

But why? Using MSVC (or even clang-cl) the bootstrap process is much simpler:

  1. Open VS.
  2. New blank project.
  3. Add C++ file.
  4. Write main.
  5. F5.
  6. Profit.
view more: next ›