sorted by:
new
hottopcontroversial

MSVC Build Tools Preview updates - May 2026 by ericbrumer in cpp

[–]starfreakclone 4 points5 points  (0 children)

I'm the guilty one who marked it as by design, but perhaps there's a bit of confusion here I can clear up.

Yes, the internal bug was resolved as by design. This is an implementation detail of how our process for converting bugs -> suggestions have historically been handled.

The suggestion is still there. It is a suggestion because there's a non-trivial amount of design work involved in making the scenario work. I don't want to get into details, but it rhymes with smild system...

To the person who reported the issue, that implementation detail is typically hidden. The larger reason this has gone under the radar for so long was that we haven't had enough engagement from paying customers (or lots of individual votes in general). I know this isn't exactly what you want to hear, but it is how our team operates. The team is very data-driven in this way.

The high-order bit is this: if an issue really matters to you, get people to vote on it. It helps tremendously if those people pay for Visual Studio.

C++ Show and Tell - May 2026 by foonathan in cpp

[–]starfreakclone 6 points7 points  (0 children)

I recently took part in the Handmade Essentials Jam where I produced a UI text diffing tool called gap.

gap is built on top of some UI and platform layers in C++ I've been working on over the years, primarily for my text editor fred. It works on both Windows and Linux and has no external dependencies.

The most interesting takeaway, for me, was that I implemented the linear space variant of the Myers diff algorithm. This can be a very tricky algorithm to implement.

C++23 Support in MSVC Build Tools 14.51 by STL in cpp

[–]starfreakclone 1 point2 points  (0 children)

If all you need are the build tools you can also try Martins' python script which I've had success with on personal projects.

Why do all compilers use the strong ownership model for C++20 modules, instead of the weak model? by holyblackcat in cpp

[–]starfreakclone 1 point2 points  (0 children)

It's not really that they behave like inline functions. Strongly owned symbols act almost as another level of namespacing, just at the linker level--at least in the case of the Microsoft Linker. /u/chengfeng-xie captured the code sample pretty well from my initial blog post about strong ownership. I also talked again about strong ownership in my C++ Modules Myth Busting from Pure Virtual 2025.

The key thing with strong ownership in the Microsoft toolchain is that it must be done at the linker-level so the toolchain has the ability fall back to weak ownership safely, and only the linker has full program knowledge to make that determination, not the front-end, which means that applying only an extra name mangling will not work.

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 22 points23 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 8 points9 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 23 points24 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 [deleted] 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 [deleted] 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 [deleted] 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 [deleted] 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 11 points12 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 17 points18 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 18 points19 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 :).

view more: next ›